The Api Wishlist Thread

[mogue]

@vV

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

[Cas]

@mogue

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.

Yeah me too, well, I had to rip said function from a taktik comment I believe.

@mogue

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

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

[Cas]

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)

[kazakore]

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.

[Cas]

I just noticed:

  
 print("vol: "..type(smp.volume_observable).." "..type(smp.volume))  
 print("pan: "..type(smp.panning_observable))  
 print("txp: "..type(smp.transpose_observable))  
 print("fit: "..type(smp.fine_tune_observable))  
 print("lpm: "..type(smp.loop_mode_observable))  
  

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)

[vvoois (vV)]

@Cas

I just noticed:

  
 print("vol: "..type(smp.volume_observable).." "..type(smp.volume))  
 print("pan: "..type(smp.panning_observable))  
 print("txp: "..type(smp.transpose_observable))  
 print("fit: "..type(smp.fine_tune_observable))  
 print("lpm: "..type(smp.loop_mode_observable))  
  

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.

[Cas]

XYPad that can also report MouseDown/MouseUp events

[esaruoho]

moved sample_recorded function names to here

[Cas]

Sample rate readout (and notifier)

[Beatslaughter]

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.

[vvoois (vV)]

@Beatslaughter

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.

[Loolarge]

Loading .xrni-files (it it possible without parsing the xml and unzipping the samples manually? )

[Ledger]

renoise.song().patterns[].track[]:add_line_notifier(func[, obj])

Only fires when the specified pattern_track is changed

[Ledger]

renoise.song().undo_observable

A notifier that fires when the user has used the native renoise undo.

[Ledger]

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.

renoise.song().patterns[].tracks[]:copy_from(other_pattern_track object, specifier_value)

specifier_value would likely be an optional integer:

1 means note_columns only
2 means fx columns only

leaving empty means all data. So the same as it works now.

[vvoois (vV)]

@Ledger

specifier_value would likely be an optional integer:

1 means note_columns only
2 means fx columns only

leaving empty means all data. So the same as it works now.

These are not fast enough?
renoise.song().patterns.tracks.lines.note_columns:copy_from(other_column object)
renoise.song().patterns.tracks.lines.effect_columns:copy_from(other_column object)

[Ledger]

@vV

These are not fast enough?
renoise.song().patterns.tracks.lines.note_columns:copy_from(other_column object)
renoise.song().patterns.tracks.lines.effect_columns:copy_from(other_column object)

Still noticably slower difference though seems it is slightly faster than the iterator version ( though I have no nums to back all this up! ).

The code is neater also so I`ll probably use thanks.

[Ledger]

Access to read and set to the send devices mute states (under device perameters)

Currently only panning, amount and receiver are visible directly in the API

[Cas]

@Ledger

Access to read and set to the send devices mute states (under device perameters)

Currently only panning, amount and receiver are visible directly in the API

check

[Ledger]

@Cas

check

Consider it plus one`d!