plus you `ve added a bit of extra polish, likeif note_column == nil then returnNo excuses now esa! get copy pasting!
I’m totally looking at what dblue posted and not only do I kinda get the logic and the solutions, it’s a really wonderful solution. Thanks a lot everyone (joule,raul,Ledger,dblue), it’s been wonderful. I can see how I can use this exact same logic for the other columns, and how this’ll make it easier to do further studies in scripting.
:excl:
It is possible to define the local above without passing it (…) and not have to type “local” all the time.
You are of course free to code however you like, but… I’ve got to say this is really quite a strange and potentially bad coding practise to work with. Where did you pick this up from?
I think this type of approach only tends to obfuscate your code, making it unclear what the precise behaviour of the function is, how it fits into the rest of your code, what arguments it expects (if any), what the exact type and scope of those arguments is, and so on.
Just because some trick or hack is technically possible within the language, it doesn’t necessarily mean that it’s always the best approach, or that you should rely on it as a (lazy) workaround to some problem that does not really exist.
So I’d personally recommend against using this approach in the future, as it’s simply not a very good technique to rely on imho, even if the code is only intended for your own personal use and nobody else.
Really… Just get into the habit of typing local … it’s only 5 characters, and it really makes your code a lot more clear and well defined 
At the very least, if you do create some function like function foo(song, x, y, z) do_something_amazing() end then you should take care to handle those arguments a bit more effectively, or treat them in a way that actually gives them more meaning and purpose within the wider scope of your application.
For example:
function foo(song, x, y, z)
-- If a song object was passed in (not nil) then use it, else grab a fresh reference.
song = song or renoise.song()
-- If values for x, y, and z were passed in then use them, else set some defaults.
x = x or 123
y = y or "Hello world"
z = z or { table = "awesome" }
end
Anyway… Just some thoughts
a notifier that detects that you’re in sub_column_type=9 could be used to trigger some certain functions?
I hate to break it to you, but no, there’s no related _observable function that you could attach to in order to detect the cursor switching between sub columns.
I do understand that you want to have Paketti react to various things being done within Renoise, but there’s quite a bunch of stuff that simply isn’t very practical in this regard.
It’s why we don’t have notifiers for things like the current playback position, for example, simply because it would get spammed like hell and bog down the entire scripting engine.
For certain things you can therefore only manually check what the current state is, at some particular interval or after some particular event that occurs somewhere else in your tool.
You are of course free to code however you like, but… I’ve got to say this is really quite a strange and potentially bad coding practise to work with. Where did you pick this up from?
I think this type of approach only tends to obfuscate your code, making it unclear what the precise behaviour of the function is, how it fits into the rest of your code, what arguments it expects (if any), what the exact type and scope of those arguments is, and so on.
Just because some trick or hack is technically possible within the language, it doesn’t necessarily mean that it’s always the best approach, or that you should rely on it as a (lazy) workaround to some problem that does not really exist.
So I’d personally recommend against using this approach in the future, as it’s simply not a very good technique to rely on imho, even if the code is only intended for your own personal use and nobody else.
Really… Just get into the habit of typing local … it’s only 5 characters, and it really makes your code a lot more clear and well defined
At the very least, if you do create some function like function foo(song, x, y, z) do_something_amazing() end then you should take care to handle those arguments a bit more effectively, or treat them in a way that actually gives them more meaning and purpose within the wider scope of your application.
For example:
function foo(song, x, y, z) -- If a song object was passed in (not nil) then use it, else grab a fresh reference. song = song or renoise.song() -- If values for x, y, and z were passed in then use them, else set some defaults. x = x or 123 y = y or "Hello world" z = z or { table = "awesome" } endAnyway… Just some thoughts
Yes, you’re right. I was just pointing out that it’s possible. In fact, it is necessary to declare the local within the function to use it later inside of the function, but it will return an error.There is no way to “escape” from this.
Another way to save writing “local” continuously is if you have to define several locals that do not depend on each other at the beginning of the function:
In this case, if the definition of a local variable depends on another, the latter must be previously defined as local, separately in some upper line.
Another detail is that each local can be defined in any line within the function, where it is convenient and is necessary, it does not necessarily have to be defined at the beginning of the function.And finally, I think I remember that there is a limit to define locals within a function,established at …200???.The number is quite high.I would have trouble seeing a function with more than 200 locals.We usually chop everything into smaller functions.These are all curious things.
I recognize that this issue of the use of global variables, local variables, performance when establishing the locals within each function and even the reading of the code is what it has cost me the most to learn from the beginning. For example, I’m still reading code that does not even use the tree structure, written by others programmer, and it’s hard to read verticaly.
So any rule of correct use (performance) or of reading should always be welcome.In fact, this makes you like the code more, finding that more efficient use, writing more clearly for others to understand and even using “tricks”, if you can call them that and that are not necessarily to avoid problems.
They are just thoughts too.It’s curious. Although the LUA language is the same for everyone, everyone uses it in one way, and although we are all doing the same thing, it has a lot to do with the easy reading of the code, regardless of whether it is optimized or not, that there are two different things.
They are just thoughts too.It’s curious. Although the LUA language is the same for everyone, everyone uses it in one way, and although we are all doing the same thing, it has a lot to do with the easy reading of the code, regardless of whether it is optimized or not, that there are two different things.
That`s the balance that needs be struck! A rule of thumb I go by is that readability trumps efficiency until you get into critical tasks, …then lots of comments come into play.
…If I manage to achieve said readability, is another matter …
I hate to break it to you, but no, there’s no related _observable function that you could attach to in order to detect the cursor switching between sub columns.
I do understand that you want to have Paketti react to various things being done within Renoise, but there’s quite a bunch of stuff that simply isn’t very practical in this regard.
It’s why we don’t have notifiers for things like the current playback position, for example, simply because it would get spammed like hell and bog down the entire scripting engine.
For certain things you can therefore only manually check what the current state is, at some particular interval or after some particular event that occurs somewhere else in your tool.
yeah, i fully getcha - some notifiers would be total firehoses and both bog down the script and the app…