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
Numba one (i probably mentioned more number ones but anyhow… just HTH)
vb:sliders that can actually center a panorama/transpose/finetune at zero (hope this is clear… I mean just like in interface it’s kind of non-intuitive how the Center value has half bar filled… for in renoise of course it’s ok for me but would be really nice to have it for guis in tools. Also goes for :rotary)
Better access to the Sections in the Sequencer.
renoise.song().sequencer.section_sequence - table similar to renoise.song().sequencer.pattern_sequence but with the sequence index of the start of each section.
renoise.song().sequencer.section(index) - to access the table.
gives like ‘Observable number’ and more of this type ‘plain’ Observable.
but to call it an ObservableNumber so one could actually bind it to sliders or so, … please please? (I still hope I’m overlooking something)
If you want to do something with that figure, why not stuffing that into your own global array?
If you want to bind an observable to sliders, have a look at my pitch device routine, i use observables all over the place that get bound to sliders.
Not really a feature request for the API itself here but a small tweak which is overlooked currently. Renoise needs a solution to correctly load precompiled tools like Live Dive regardless of the bit version. I’m using the 32 and 64bit versions of Renoise and it’s only possible to use Live Dive in one of them and the other greets with an error. A possible solution could be to expand the tag in the manifest.xml file to target specific bit versions, so the tool could be loaded in one version and the error is omitted in the other. With proper file naming an author could make x86 or x64 specific versions and simply allow installing both at once then.
The platform tag is a good idea.
An error should not be omitted at all unless one tries to install a bit-specific version during that moment, but once installed, it should not be executed and listed. But i’m not sure if packed binaries are scannable.
This is a request to speed things up in my Sync notes in group script. I have added an option which uses an iterator to just copy the note column data but it seems to run a lot slower than the API copy methods.
These are not fast enough?