With this you could for example do:
-- setting up
if xinc == 1 then volume_osc = osc.create(sine, 16, 0, 255) end
xline.note_columns.volume_value = volume_osc:value()
Update: I think it's almost done here. Might need some bug fixing and tidying things up. + Documentation (it's quite flexible)
Not sure danoise will find it useful enough, but I for sure will use it anyway
Another (totally different) idea I got is a very small and simple helper function that could be available in xStream that I would find quite useful and that would possibly simplify some aspects of xStream coding even more. The following:
if on_update(xline.note_columns.note_value) then
xline.note_columns.effect_value = 10
Super simple syntax imo.
on_update() will return the value only when changed, otherwise it will return nil. The idea is also that the on_update() function would not only accept variable data, but even a whole object (excl methods).
It should be pretty easy to code. I imagine that the first time on_update is being ran, it will register the reference in an internal table (variables would be normal values and object/tables would be hash values). Registering/checking objects and tables would require some recursive scanning, sure. On each subsequent update it will compare the current value to what is cached. Not sure how to get the "uniqueness" of the parameter passed into the function, but it should be possible? Or maybe there is a better way already available for similar tasks?
EDIT 2: An alternative would be to hook up a document to xline properties, and make use of document observables? Observing xline is quite enough, I think, maybe allowing for something like this if possible:
if xline.note_columns.note_value:is_updated() == true . Or is something similar already possible?
Another simplifying idea, or at least one that adds flexibility, would be to provide not only xline but also something like xline(offset).
xline(16).note_columns.effect_value = 10
This is sometimes more convenient than 1) caching values for later use or 2) calculating the correct value with a possibly more intricate function (offsetting), 3) dealing with xpos.
A very simple practical example would be to generate a tracked delay in a second column. In this case xline(steps) would imo make more sense, or at least be easier, than storing data in a table for % search or fetching data from previous lines.
Just an idea for streamlining/simplifying model coding and improving readability, making new users feel even more welcome
Edited by joule, 13 July 2016 - 09:46.