[L2Ork-dev] coin-operated scripting language

Jonathan Wilkes jon.w.wilkes at gmail.com
Thu Oct 10 20:03:11 EDT 2019

On Thu, Oct 10, 2019 at 11:24 AM Ivica Bukvic <ico at vt.edu> wrote:
> Thank you, Jonathan. I like this as a fresh approach to allowing computation that maintains sync with the main thread. That said, I wonder what advantage this may have from designing simply an external that processes some kind of a potentially existing script and which runs in a separate thread and outputs whenever ready?

To maintain determinism you'd need to specify a precise clock callback
time at which the results of the script are output. And if the
thread still isn't ready at that callback you'd need to block the main
thread until it is.

Additionally, I think there's a greater ease with which the coin
operated vm  can be extended and abused. If users really wanted to
be able to mutate global state from within the script (say, send to a
s/r symbol or write array data) anyone could do a sloppy job of
it in a commit and it would probably work. Judging from stackoverflow
incorrectness wrt writing a threadsafe refcounting algorithm, I
posit that anyone trying to do the same with a threaded design would
be merging all kinds of subtle bugs into the mainline repo.

> This is how many of our input devices function with their input ostensibly being considerably slower than the interrupt of the main thread (e.g. mice/trackpads and wiimotes). This way the main thread only keeps the last data point stored until the next one is generated and outputted by the external. It seems to me that may be an easier approach than trying to somehow impose coin counting which may be difficult to account for given the CPU utilization will change with a growing complexity of a patch, thereby leaving less time for the object to do its thing before the audio buffer is starved and we get an xrun (assuming the patch involves audio).

If the user will only ever need to sample the incoming data from the
worker thread that would make sense. But surely users will sometimes
need the entire lossless stream of data from the script, no?


> Best,
> Ico
> --
> Ivica Ico Bukvic, D.M.A.
> Director, Creativity + Innovation
> Institute for Creativity, Arts, and Technology
> Virginia Tech
> Creative Technologies in Music
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> ico at vt.edu
> www.icat.vt.edu
> www.performingarts.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
> On Wed, Oct 9, 2019, 22:48 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> Hi list,
>> Ok, I've got a little scripting language prototype coded up
>> as a Purr Data class.
>> It's something like this:
>> [vm var1 var2 etc.;
>> + var1 42 10;
>> / var2 var1 5;
>> etc. etc.]
>> The idea is that you put your parameters on the first line, then
>> you can refer to them in the body.
>> At the moment I'm just using this notation: "operator destination
>> operand1 operand2." It's pretty easy to map another more user-friendly
>> syntax on
>> top of that with a Pratt parser or something.
>> Currently I'm just setting a single parameter from the right inlet of the
>> object. Once the computation is done, the return value(s) can come out
>> of the right outlet.
>> The novel business happens in the left inlet/outlet
>> [bang, 12(
>> |
>> [vm foo;
>> + foo 20 1]
>> |        |
>> [vn bar;
>> - bar 63 bar]
>> |
>> [etc.]
>> The "bang" tells "vm" to get ready for computation.
>> The float method then sends 12 "coins" to the inlet. That means
>> that the object is allowed to do 12 operations before it suspends
>> computation.
>> Notice in the first [vm] we've only got one explicit operation-- adding
>> two numbers. There's another implicit operation where the return value
>> is sent to the right outlet. So even though we had 12 "coins" to start,
>> our computation only used up 2 of them.
>> After the right inlet spits out the output, the left outlet spits out the
>> "change"-- the leftover "coins" that went unused. Thus, the
>> next "vm" object receives "10" coins to its inlet.
>> And so on and so forth all the way down the chain.
>> So what happens if we don't give a "vm" enough coins to compute its
>> output? It just halts. But you can resume the computation where it left off
>> by sending more coins to the left inlet. (If you send coins after computation
>> is finished the "vm" just passes them through.)
>> AFAICT this lets us deterministically suspend and resume computation in the
>> control domain without blocking DSP. Consider:
>> [bang~]
>> |
>> [20(
>> |
>> [vm var1;
>> some large number;
>> of operations in this;
>> script to calculate;
>> some values for a;
>> physics engine;]
>> Even though the script may not be able to finish in time for a DSP
>> deadline, we're only computing 20 operations of the script each block.
>> That's very unlikely to interrupt the audio. So as long as we can reach
>> the end of the script in time to update the graphics or whatever we're
>> trying to achieve, then we should repeatedly hit those deadlines without
>> a problem.
>> Additionally, we can afford to be rather sloppy with the features here. We
>> can allow the users to make loops, even infinite ones, without fear of
>> locking up the running Purr Data instance. Of course allowing fancier
>> branches and loops in the scripts increases the likelihood of surprises
>> wrt the number of operations to compute the output. But Pd users seemed
>> used to testing weird things until they kind of work.
>> Anyhow, I'll keep adding ops to this and start looking into some more
>> friendly syntax.
>> The real sticking point will be the entry and exit points. I don't think we
>> want to allow arbitrary and/or dynamically sized lists and arrays to
>> be read and written. Otherwise we'll have to copy lots of data to protect
>> against stale references, and that will easily become a performance
>> bottleneck. But I think there's a way to require statically-sized,
>> protected data inside the "vm" while still getting pretty expressive
>> operations in the script.
>> -Jonathan
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev

More information about the L2Ork-dev mailing list