can’t wait till it is ready for prime time! 
Allowing duplicate values in lists in a Document (see https://code.google.com/p/xrnx/source/browse/trunk/Documentation/Renoise.Document.API.lua#256) and then being able to iterate through and identify these and handle them pretty much like you would a table, or let Document contain tables with observable values in it instead of just lists.
Say you have a group of volumes, and then you have individual volumes that you want to bind to sliders in the view.
Now you have
volumes = {
volume1 = { value = 10, line = 1 }
volume2 = { value = 20, line = 4 }
volume3 = { value = 30, line = 8 }
}
and can do volumes[“volume” … id]
but it would be great to have
volumes = {
volume = { id = 1, value = 10, line = 1 }
volume = { id = 2, value = 20, line = 4 }
volume = { id = 3, value = 30, line = 8 }
}
and be able to do both volumes[id] or volumes.volume.id.
So you have the choice to either identify a volume by it’s position in the volumes list, or by it’s specific, unique id.
Also a few wishes for the document API, which makes it somewhat cumbersome to use in my case as it is now.
I can add nodes with doc:add(name, node) but can’t delete the damn thing with doc:remove(name, node), remove() only supports the full document or a list entry. Looks like i have to rebuild the whole document to get rid of a node, but this can be solved in a preferred way like below:
Probably even more useful and much more powerful would be to support a list of nodes instead of only numbers, strings and booleans. As it is now i have to use a structure similar to this:
<mixer_snapshots>
2
<snapshot_1> … more tags inside … </snapshot_1>
<snapshot_2> … more tags inside … </snapshot_2>
</mixer_snapshots>
A list of nodes would allow me to do it like this:
<mixer_snapshots>
… more tags inside …
… more tags inside …
</mixer_snapshots>
#mixer_snapshots.snapshots would return 2 too in this case and what’s even more sweet… mixer_snapshots.snapshots:remove(pos) should work, so the first request solves itself. mixer_snapshots.snapshots[i] returns an observable list and mixer_snapshots.snapshots[i].value a DocumentNode object.
You can. Simply leave away the name:
local doc = renoise.Document.create()
local nested_doc = renoise.Document.create()
doc:add(“sub_node”, nested_doc)
doc:remove(nested_doc)
… should do the trick.
Well, this is only half the truth because in the remove you’re still passing a DocumentObject and not a DocumentNodeObject. The problem is that in one function i’m storing all the snapshot values and also create temporary DocumentObjects, which i’m using to add all the stuff, the function exits and they are gone. Now in another function i want to delete a specific snapshot and use node = doc:property(“snapshot_” … index) to get access to it, but now i do have a node object and not a document object anymore. The only way it works would be to make some sort of global table and memorize each temporary used document for all snapshots and these would be a lot.
There only is a DocumentObject. Nodes are DocumentObjects which got added into another DocumentObject.
If you no longer have a ref to it, then get the ref from the parent.
– using the example above:
doc:remove(doc.sub_node)
– or
doc:remove(doc:property(“sub_node”))
EDIT: IC. The docs are not clear about this. Will fix this…
Aha, there is the culprit. Wasn’t aware that one can get parent objects too and that both are the same type. The request for the list would still be handy though. Modified my storing now to something like <snapshot_crc32> instead of <snapshot_1>, so the position of a snapshot in a document isn’t that relevant anymore. When i rename a snapshot i can simply fetch the node into a temporary document, delete it and insert it again under it’s new name.
So just to sum it up and drive it home with taktik’s example
local doc = renoise.Document.create()
local nested_doc = renoise.Document.create()
local nested_doc2 = renoise.Document.create()
doc:add("sub_node", nested_doc)
doc:add("sub_node", nested_doc2)
doc:remove(nested_doc)
rprint(nested_doc)
outputs
and if you do
local doc = renoise.Document.create() {
sub_node = {},
sub_node = {}
}
the sub nodes will overwrite eachother (like the docs say).
It would just be a lot easier if you could have nodes with the same name and ref them like Beatslaughter mentioned.
I was thinking if E4X existed for Lua and found this but not sure what happened to it.
Yes, creating lists of Document objects indeed is something that’s missing right now. The only reason why its not yet there are some hard to describe implementation details which I haven’t found a solution for yet. Will try to take care of this.
renoise.app().window:select_preset_observable:add_notifier(foo)
and a way to tell which preset it moved to from the defined foo notifier function
if this is possible already i’d love to know how.
some simple ViewBuilder drawing elements. like curve, (circle) line, (square).
Instrument scripting.
right click instrument to load script as instrument.
Meta-device to scripting linkage.
meta-device with a couple dropdowns"
dropdown, select script.
populate fields with script functions.
other meta-devices would list this meta-device’s functions and available parameters.
edit<<< for clarity
switchable pre-mixer / post-mixer view. I know this isn’t even possible for midi mapping right now, but a lot of controllers offers bank-switching (like e.g. the NanoKontrol).
And the thing should be observable, too 
[s]One for the pattern iterators:
pattern_iter:note_columns_in_pattern_track(pattern_index,track_index,line_index)
i.e. the line/row in the pattern to begin the iteration from.
[/s]
I want to say that you’ve done great job creating this API. I was surprised by the number of available properties/functions etc.
I just started developing my own tools. Currently most missing:
- renoise.song().transport.playback_pos_observable
- ViewBuilders bitmap supports only notifier. But pressed implementation would be blessing…
Cheers!
API for access to renoise’s 4 clipboards.
Hey Konrad,
A solution to this could be adding an idle notifier that checks the playback_pos. If you take a look at Nibbles, you’ll see how the idle notifier can serve as a game stepper. You can change the os.clock() time checker to a playback_pos checker.
-- Run every line
if (renoise.song().transport.playback_pos == last_idle_time) then
return
end
last_idle_time = renoise.song().transport.playback_pos
For heavy processing you will encounter “frame dropping” when the idle notifier doesn’t fire between playback_pos. It will skip a line so to speak so keep that in mind when creating the stepper.
You can add and remove the idle notifier on renoise.song().transport.playing_observable to reduce overhead.
I seem to be developing a tool in a similar genre as you, it writes to the pattern editor during playback at the playback_pos. I hope to post it in a few days but I could send it to you (i if you want to take a look at how I address these issues.
I ask for a way to know the current sampling frequency of the audio driver, so that the creation of samples can take it into account
- Some way to define selections in Pattern Editor