Basically, we have two methods for scheduling a pattern using the API:
-- Append the sequence to the scheduled sequence list. Scheduled playback
-- positions will apply as soon as the currently playing pattern play to end.
renoise.song().transport:add_scheduled_sequence(sequence_pos)
-- Replace the scheduled sequence list with the given sequence.
renoise.song().transport:set_scheduled_sequence(sequence_pos)
But, unfortunately there are still important aspects that are missing. Please correct me if I’m wrong, or some kind of workaround exist
1.It’s not possible to clear a schedule once it has been set
I imagine this could be implemented simply by calling set_scheduled_sequence with no argument,
or we could have a dedicated clear_scheduled_sequence method?
It’s not possible to read or observe the schedule list
This is something that has been a showstopper for me on a number of occasions.
It would be nice if we could at least access/read the list, and act accordingly.
I am trying to do something seemingly simple here,
Ignore any changes to mute-states in the pattern matrix when tracks are being swapped
But, the thing is that the notifier for tracks is being called after the mute slots notifier!
Not sure that makes sense, so consider it a API request that the calling order is changed:
General principle: if event (foo) can cause a successive event (bar), always put foo before bar
I have found myself come up with a hackaround which works only when tracks are
deleted or inserted: basically, check the number of tracks against a memorized number,
and allow the handler to continue only if the number has changed. However, this will
not work when tracks are swapped, as the number would be the same
I’d like to see a ViewBuilder Valuefield element property “edit_mode”, similar to Textfield element.
The background for this is that right now it seems overly complicated to make a dialog that would have a valuefield that you could focus with a keypress event, in turn making it hard to build keyboard driven tool dialogs.
It’s possible to hack around this using the Textfield element, but the valuefield edit_mode would seem like a more developer friendly solution.
(trying to make a proper version out of the “Dancealot” tool that would provide improved ways of adding dsp to a track, e.g. with instant preset handling)
Yeah something like that. I didn’t delete the post but I was so stupid to make it a new topic. Exqueeze me.
as for the names, yes, only that the : colons will actually be . points, and naming well anything that makes it very clear you can have 2 positions. maybe just a loose function that returns the pattern belonging to a songpos, but that would be probably only used in conjunction with either edit_pos or playing_pos.
Glad you ask. I just made a small tool called MiniTab that provides kb shortcuts which make about the same movements as Tab/Shift-Tab normally, with the only difference (now) being they don’t skip effect columns. At first I wanted it to also have shortcuts to move through v/p/d columns, just because it’s always 3 times to the right (cause I never edit instrument number by hand)… it’s a minor glitch/missing thing in my eyes.
Also, please note that I might just scream bullshit out loud sometimes convinced that I got the only truth, it might have sth to do with me moving from normal 104 key keyboard to laptop keyboard with very different layout so I’m setting up to move comfortably. For me this brings new things like making <50 LOC tools just to be able to do things with one keystroke instead of 2. or 3.
This is a great idea. I’d love to see like this for more abstract document traverse-ing. I have sometimes needed to construct functions that figure out the index or parent of an item which has huge overhead.
To put it in general terms; All objects that appear within a list in renoise.song() could use an .index property (returns a number) and a .parent property (returns an object).
Yeah this was requested indeed and really necessary because tracks can get swapped (or renamed) and you then no longer know which track your script was working on because you have no unique number where you can rely on in that case.
Don’t forget the parent reference! When scripts get deep, with very abstract functions that are highly object oriented the need to traverse upwards from say a NoteColumn or TrackDevice becomes great. Currently you will often find yourself passing both a sample and it’s parent instrument to a function, this doesn’t sound too bad until you start passing these arguments through functions to other functions and returning tables with many objects just to retain your absolute document location.
EDIT: A parent_index would also suffice as suggested by Cas, but I think a direct reference to the object is more computationally effect as then we would skip looking up the object via. renoise.song():instrument(sample.parent_index) and we could directly access the index via. sample.parent.index
Yeah me too, well, I had to rip said function from a taktik comment I believe.
I think we should have both functions. It’s just as easy when making it in C, and helps clarity about doc traversing.
In the case of e.g. DeviceParameter a simple parent_index wouldn’t be enough though, so you’re definitely right about need for simple .parent props
