The Api Wishlist Thread

Renoise Tool Development
220

Thing with this is that you were originally talking about delay values within a note column, not line indexes :slight_smile:

But yes, I know what you’re referring to, and we are indeed missing a proper phrase-based equivalent of renoise.song().transport.edit_pos, which understandably hinders what tool devs can currently achieve. Adding such a property should of course be feasible… at some point in time. (Shout at danoise and taktik, not me, haha.)

Yeah, I did get Phrase Delay-writing (much like Pattern Delay-writing in PakettiR3) working, but then realized that there was no phrase_line_index :slight_smile: I won’t shout at you, I’ll shout at taktik+danoise, but I’m sure they’re busy with life, work, other things.

Would that really be so useful, though? I’d guess that you and I probably have fairly different view presets saved locally, based on our own common tasks and personal workflow needs.
If I switch from preset 1 to 2, but your tool doesn’t know what my preset actually is, then what? I guess you could manually read each view property one by one — renoise.app().window.disk_browser_is_visible, renoise.app().window.active_middle_frame, renoise.app().window.pattern_matrix_is_visible, etc. — and then make some kind of educated guess about what I’m seeing, but that doesn’t seem very ideal imho.
But for your own private use and finely tuned personal setup, sure… such a thing would still be useful, and doesn’t really hurt anyone if it can be added. :slight_smile:

I uhh… Must admit that it’s pretty much just a hope that_maybe_ it’d be useful. Like having a specific View Preset that starts pattern-length sampling when triggered, and then returns to the pattern editor when sampling stops… This kind of stuff. I just had a feeling that maybe it would actually be useful. Most of these ideas are fledglings until you flesh them out and make them into workflows. Before they’re worked out, approved, logical and robust workflows, they need to kinda be bashed around until you get the goods out.

…

Yeah, the whole “launch function when view preset” only makes sense, if the scrip is allowed to destructively mangle view presets. or, if LUA scripts themselves have their own View Presets that are outside of the “Renoise basic 1-8 View Presets”.

Actually, that’d be nice - you could leave the 8 View Presets well alone and instead “save Tool-Specific View Presets” and allow the user to open them, if they like.

221

Hi,

the parameterlist-hide-state of a dsp device seems to be not available thru the API. Onlyrenoise.song().tracks[].devices[].is_maximized is there, but I cannot find an “is_expanded” boolean…

222

automation_pointer:add_point_at(pos, value, EVENT_OPTIONS) whereEVENT_OPTIONS are like “DO_NOT_TRIGGER_PLUGIN” / “DO_NOT_BUBBLE_EVENT” or similar for the moment of adding the point. e.g. adding a point after a vat-parameter-change trigger.

EDIT: Or fix automation following song option, since it interferes with automation writing!

223

the parameterlist-hide-state of a dsp device

What would that thing be, anyway?

The small “tree” in the left side of the envelope editor panel, listing parameters … or something else?

224

What would that thing be, anyway?

The small “tree” in the left side of the envelope editor panel, listing parameters … or something else?

Yes exactly that, so the parameters are visible then

225

Please add: (to switch that song mode using lua)

renoise.song().transport.automation_following
-> [boolean]

Please change:

renoise.song().instruments[].plugin_properties.plugin_device.external_editor_visible

to: (to capture closing-gui-clicks)

renoise.song().instruments[].plugin_properties.plugin_device.external_editor_visible, _observable
-> [boolean]

Please add: (to make a track dsp device’s parameter list expanded)

renoise.song().tracks[].devices[].is_expanded
-> [boolean]

Please add: (To temporarily disable automation reading for a specific vst parameter a.k.a. bouncing automation value to vst, e.g. while writing automation to a vst parameter of a effect, so you could somehow get a delta between the vst value and the audio device.slider value, to detect manual movements of a gui control)

renoise.song().tracks[].devices[].parameters[].reading_automation, _observable
-> [boolean]

Please add: (_saving instead _save, to trigger just before song will be transformed into xml and saved to disk, the right moment to place custom data to the song, currently song comment only. Currently the trigger only seems to be available AFTER the song was saved AFAIK)

renoise.tool().app_saving_document_observable
-> [renoise.Document.Observable object]

Optimization of active_preset_data

Also the performance of writing active_preset_data is pretty low. If you do that multiple times a second, it will cause heavy slowdowns, or even freezes. For instance, if the new parameter position matches the old parameter position, there is no need to resend that parameter to the vst. Maybe it could be optimized on other places, too…?

Also it would be super helpful, if the active_preset_data would contain the LinkedInstrument-value. Currently that is only available if you copy the settings of the device, but not from LUA.

To discuss:

Maybe add: (To allow to add custom data. Just like comments, only that this field is visible only in developer mode)

renoise.song().custom_data[], _observable
-> [array of strings]

Maybe add: (So the next/current undo step will be joined with the last step)

renoise.song():join_undo()
226

Multitimbrical phrases !!!

Not only one instrument per phrase.

I want to trigger more than one instrument in the same phrase pattern

227

To discuss:

Maybe add: (To allow to add custom data. Just like comments, only that this field is visible only in developer mode)

renoise.song().custom_data[], _observable
-> [array of strings]

This (or similar) is a feature that has been mentioned a couple of times. Also by Danoise, so I guess he already has an idea on how it could be implemented.

Otherwise, I imagine the following:

  1. Any Renoise object should be able to store additional user data as ObjectType.user_data (table, or rather “DocumentList”).

  2. example of how to add new data: PatternLine:attach_data(key, Document). Keys can either be indexed or not. Potentially, it’s probably even a good idea to store the data as ObjectType.user_data[tool_name][key]. This is to restrict write-access per each specific tool. Of course, any tool can read any tools data however, as full read access to the user_data table is always available.

  3. By using the Document classes, I imagine that it’s relatively “easy” for the devs to implement serialization/deserialization to/from the song data.

  4. Limit the number of keys in any DocumentList to, say… 256. Avoiding the risk of accidentally spamming user_data and saving a big ass song.

  5. Something to consider… Would it be easy to even get observables going 100% in this structure? Otherwise it wouldn’t feel 100% consistent.

Yup… I think I pretty much explained how to implement it properly here :wink:

228

I generally agree here, but

  1. it should be a simple LUA table. XML manipulation is annoying in Renoise LUA API. DocumentNode etc, cmon that’s way too old school anal. The table could be also recursive, with unlimited depth. Btw. there also is json.

  2. accessible simply thru something like Renoise.song.user_data[]

2a. I know the above will never come, that’s why I requested it in the song comments way, which is pretty lame to handle (need of create a buffered comment-sum all the time). So the devs simply can “duplicate”/double-use that code.

  1. Serialization should be done by Renoise, and provide the data in tables within tables

  2. No need to limit! You already can slowdown or hang Renoise with any tool or add a gigabyte of data to the song comment. Of course you should use it carefully. Also this is not old school assembler where we need to match integer 0xFF or something.

  3. If it is a table, you could add your own observers?

  4. Taktik should convert the table then to a string, then zlib compress, and base64 it and then out it into the song xml as cdata. So it cannot break anything.

No, thats no the way you should do it what you wrote above. It is unnecessarily complicated and limited.

229

Nah… you better trust me on this. I’ve got a pretty good feel for what is consistent with both LUA and the specific Renoise API in terms of syntax and structure.

Documents are the way to go. The devs made them for a reason and it makes no sense to not use/inherit those classes. Otherwise they’d start to make ad-hoc structures that aren’t internally consistent with what is already there. The whole API is document based - and quite possibly the .xrns file might actually already be a one-shot Document serialization of the renoise.song() object. Ok, maybe not quite…

But, there’s no need to argue really… It’s highly unlikely that you’ll see the devs divert from the Document structure, unless they plan a complete API overhaul breaking every tool released :stuck_out_tongue:

The only thing I’m concerned about is if user Document objects inside renoise.song can somehow be broken by abusing inheritance or other syntaxes. My idea might be oversimplified in the sense that current renoise classes rely heavily on a very restricted use.

230

As I said there is no need to directly manipulate the song xml which btw. is only created at save on not residing in the memory all the time! Renoise should provide a recursive table and convert it automatically on save. It is very easy to realize. If I would trust you here, we would get a super annoying way to store custom data, even more annoying than in comments.

Using XML for this is utter nonsense, makes it complicated for both sides!

End of discussion.

231

DocumentList is basically = 1) table, 2) observable, 3) serialization/deserialization. So there you go.

232

Writing data is to a table way more easy man! You don’t even need to prepare anything then!

Super complicated your idea.

233

It’s not my idea, really. It’s already dictated by renoise.Document API and renoise.Song API. Of course you can always propose some ad-hoc solution for this specific chunk of data, but that’s just ugly. In that case, they might as well start to “simplify” other things here and there - and break the elegance and consistency of the API completely. That would be highly unwanted.

Just imagining the designing of a special case “table” observable makes me sad. They already “invented” all of this in the Document API. But I understand that I can’t convince you due to the “scare factor” of not knowing renoise.Document API.

For an API, consistency is a lot more important than case-by-case “simplicity”.

234

Whatever way it would be, it would be helpful to prevent to use song comments, since song comments original purpose was for song comments.

235

To make a preset manager in lua possible, please add:

-- Renoise will auto-add the file ending dependent on device type (internal/vst/au)
renoise.song().tracks[].devices[]:export_preset(preset_path)

renoise.song().tracks[].devices[]:import_preset(preset_path)

-- Insert a new device by preset at the given position. "preset_path" must be contain a valid file path the the loadable .fxp or .rdxp
renoise.song().tracks[]:insert_device_by_preset_at(preset_path, device_index)
 -> [newly created renoise.AudioDevice object]
236

To make a preset manager in lua possible, please add:

A lot of this is possible. It’s located in the Application API, not the Song API:

https://github.com/renoise/xrnx/blob/master/Documentation/Renoise.Application.API.lua

For some reason, the ability to save track device presets is missing. Not sure why, but the rest is covered

237

Ok that’s nice. But see, I would like to do a fxp -preset and plugin manager. Since my above suggestions are not available, my plan is not realizable currently. If you would add those already existing functionality to the API, it would highly improve the possibilities. Would be also nice to know if you already planned to improve the vst browser, so my work would be obsolete :). I doubt that, because I bet you focus on other spots.

238

Make renoise.Sample.sample_buffer_observable (or some new observable) react to any changes to the sample data.

There doesn’t seem to be any way to monitor changes to sample data at the moment.

239

A lot of this is possible. It’s located in the Application API, not the Song API:

https://github.com/renoise/xrnx/blob/master/Documentation/Renoise.Application.API.lua

For some reason, the ability to save track device presets is missing. Not sure why, but the rest is covered

danoise, so do you mean that “renoise.app():load_track_device_preset(filename)” will load a fxp, too?