as my first epic project I tried to make the custom waveform generator “realtime”, that is, when you move a slider the sample gets automatically updated
I’m not going to bother you with stuff I can find out myself easily (like how to make a checkbox to toggle autoupdating, for now I just use a local variable hardcoded to true), BUT before I try this more seriously… there is probably a better way than sticking a “if AUTO_GENERATE then generate() end” at the end of all the individual GUI notifiers haha? that can’t be right ^^ well maybe it is, but I’d just like to ask.
I’m sure the answer is somewhere in the docs, but I haven’t read not to mention digested all that (it’s a bit much at once, to put it mildly o_O), it’s also my first encounter with LUA - so a little pointer would be sweet, because this is kinda fun already (the waveform updating when you move sliders I mean, otherwise it’s all just a scary jungle to me).
if I can I’d like to make it somewhat solid, or at least not start with an utter mess when I could instead register a function that gets called anytime any GUI element is changed, or something like that?
oh, and what would be the process of submitting patches? just pm the author with diffs? fork? in this case it should be easy enough to just explain the few changes in the forum itself, but generally speaking?
the other thing is - generating a new sample on every GUI update creates a LOT of undo data, and the number in the sample name also continually increases. that’s no biggie for me when doodling around, but in the real world that’s not usable I guess. any ideas? is there a way to suppress generating undo data and increasing the sample number?
another idea/question: updating the sample without stopping playback, that is, when not changing the length, instead of replacing all sample data, using something like the sample draw function… is there something in the API for this?
okay, now I’m really asking instead of looking myself, but if the answer is “no” for some reason, it would save me the trouble of looking at stuff that makes my head spin hehe.
during the first alpha stages I created a script which allowed to draw the sample in realtime using a MIDI knob (I will post it as soon as I will have the time), so changing sample data on the fly is definitely possible, but I don’t think you will be able to avoid the big undo processing, unless of course you disable undo for the sample you change
after the changes. when undo is enabled, this will set an undo “bookmark”, but it’s good practice (read: mandatory) to add this line of code even when undo is disabled
I am appalled at how easy it was to add create a checkbox just with copy & paste and guesswork… of course, the real deal is updating it in real time, and maybe being more elegant about the GUI notifiers… but yeah, how would I share this with the world/you eventually? just so I can take the necessary things into account right away.
unless you think you finished with the script, it’s better to use private messages in order to exchange .lua files.
once the script is finished, use tools.renoise.com to publish them.
note: the scripts will be reviewed before being published, so they will not appear on the tools page immediately
… but let’s please avoid that everyone’s branching a new tool from an existing tool, just to add a single new feature to it.
If you have made some improvement for a tool, contact the author of the tool and work with him together and let’s update the original tool. Lets collaborate on this. You both are already in contact, but just wanted to have that said again …
Yeah. If someone makes some new features in scripts, they can send patches to the original author. No point in creating multiple forks of tools under tools.renoise.com, unless it is ideologically different, merging the features is impossible and the new fork offers some benefit over the original.
yeah well it’s nowhere near “finished”… well, actually it nearly could be I figure, but besides that I’m not sure if it’s okay to insert all those individual conditionals, I’m kinda puzzled by one thing:
how do I (in the function generate()) detect if the sample length changed (so I can skip the creation of a new sample in that case)?
I tried “buffer_new.number_of_frames == real_cycles*int_frames” but that never triggers scratches head
who I said I even dreamed about doing this? I specifically asked about forking, pm’s and diffs, way near the top… and most importantly, if there is a place that gets called when anynotifiers change GUI buttons/sliders get changed. that kinda should tell you I’m really trying to actually produce something that can be used and reintegrated, instead of just something that does what I wanna do and upload that.
but since I’m really poking around in the dark alot, I either am chatty and a bit of pest (it’s not like you have to answer my questions, but I need surely to ask them, be it just to answer them myself later on), or I just fumble around with something that will eventually benefit nobody (or would take more work to patch in than for someone know already knows what they’re doing to do it themselves).
YAY! that did it. it’s a bit clicky when updating, but otherwise it seems to work perfectly! unless I forgot a notifier for some GUI element of course. I will review it later today, make a note of the changes and send that to it-alien.
and yes, I really need to read some basic LUA tuts before I progress further, I don’t know anything.
I vote for github.
Git is way better than SVN for such a thing (note: not EVERYthing!), as it is highly community driven. The distributed nature of git works like a charm for such projects, as you don’t have to manage commit rights. It takes a little time to get used to the distributed, fork-driven development, but it’s worth it. I tend to manage all of my private coding using git, whether public or not.
well, the latest news is that somewhere between cleaning it up, adding stuffs I broke it haha… the thing I sent it-alien stops auto-updating as soon as you change operator tabs, and I swear it didn’t do that earlier
I am really clueless as to why that’s happening now, and to be honest there’s only so much staring at code I hardly know I can take in one day, so I’ll have another go tomorrow I think…
I don’t know if Johann is referring to the fix I have sent him some minutes ago, anyway I have also fixed it
this auto-generation system works very well and it is very comfortable to use; I actually think the “Generate” button is superfluous now and should be removed, leaving auto-generation always enabled, what do you think?
edit: if you want to try out the automatic generation in order to decide if Generate button should be removed, use the attached version
This really works great for very small waves! At base note C-0 this is very noticeable though. I’d keep it as option. Maybe simply turn it on by default?
And here’s a patch (well, file) to make the GUI pretty again:
