The Api Wishlist Thread

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.

XYPad that can also report MouseDown/MouseUp events

moved sample_recorded function names to here

Sample rate readout (and notifier)

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.

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

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

Only fires when the specified pattern_track is changed

renoise.song().undo_observable

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

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.

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.

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 ;)

Consider it plus one`d!

--Selected in the automation editor view. Can be nil.  
renoise.song().selected_parameter_index, _observable -> [read-only, number or 0 (when no parameter is selected)]  

can this be made setable rather than read only?

You can create your own set of controls in the LUA GUI widgets for Renoise and allow them to change the parameter directly. This is really the way to go rather than intervene directly with user controls. (this can be experienced as highly annoying).

So you`re saying selected parameter index can be set??

renoise.song().undo_fired_observable  
  
renoise.song().undo_returned_observable  
  
renoise.song().redo_fired_observable  
  
renoise.song().redo_returned_observable  
  

A request for two notifiers linked to undo being called in renoise.

The first one notifys when the user has pressed Ctrl + X in renoise. Whatever function is attached to this notifier is called before the undo is executed in renoise.
The second one is called when the undo has returned in renoise.

This means you can release other notifiers in your tool (like pattern_track_line) to stop them being triggered a load of times by renoise undo. You can then add them back after the undo is finished.

edit: Also for redo

(it maybe renoise.app() but you get the idea)