Numba one (i probably mentioned more number ones but anyhow… just HTH)
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.
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
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
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).