I was going through the valuable contributions here and thought that server side operations are fundamentally limited in SC.
Alot of SC scheduling seems to be about passing around arrays of data.
But this doesnt make alot of sense for server side sequencing imo. What you probably want for server side sequencing are Ugens with a small set of modulatable params, probably at audio rate which give you a lot of range between predictability and chaos.
If you for example want to setup a server side sequencer based on demand ugens, which takes an array of subdivisions per measure, you would probably want to change that array of subdivisions at some point. But the moment the new data should be evaluated is not the moment when you set new data from the language but when the server side sequence starts a new measure, so the server side sequencing should store the users request for new data until the new measure begins and not vice versa.
I have made some tests with that in gen~ where the request to update the array of data is stored in a temporarily data set before its evaluated by the next request when starting a new measure. I have also implemented the SchedulerBurst Ugen which tries to be a hybrid approach between language and server side sequencing and is capable of sub-sample accurate audio rate ratchets scheduled by the language. Im not sure if anybody has noticed that.
The Durn Ugen i mentioned in the thread is a good example i guess of what you want to expect from server side ugens, possibility for change on every draw with a small set of params
I just wanted to collect some recent thoughts with this post, if you also have some let me know
One way could be to store your arrays in pairs of consecutive Buffers, one to be written to and one to be read from.
Then you would swap the read and write buffers at the start of each measure - for example using ToggleFF as readBufferOffset and (1 - readBufferOffset) as writeBufferOffset.
If you store the current writeBufferOffset in a single value Buffer, then you can write to the correct buffer from the Language or Server.
Best,
Paul
I’ve been working on an approach to this for quite some time now :~)
It’s a small DSL which combines function chaining with a tree structure (think of a branch with functions as its nodes, each argument of a function could branch off and then be mapped to a new function. All phase/time information is transported upwards in the tree, meaning that every change I make to the phase in the one node is also happening for all the argument’s nodes and so on…). Its quite similar to Strudel/TidalCycles with how it handles time.
It’s very much WIP, but useable. I’m happy to share a preview when I get back to the computer.
Some main concepts that seem to work well for me:
The main Phasor driving the system (with a very high/inf wraparound, still working on finding a good value) is in a separate node from all sequencing/sound generation and automatically reiniated at Cmd-Period
Every function that is reliant on the Phase signal gives always the same output for the same phase value (deterministic)
Recently I have been playing around with something that I call step/index rate (for lack of a better term): Generating a signal that counts up “events” instead of a linear ramp for the phase signal. Then you can work a bit like in the Pattern System, but on the server.
This enables swapping out the sequencing logic at any time (without having to worry about state) and also modulating everything at audio rate.
I’m very interested in the stuff you’ve been posting recently! I’ll check out your DUrn implementation as soon as I have time, seems very promising!
All best and a good start of the year to everyone!
