[L2Ork-dev] coin-operated scripting language
ico at vt.edu
Thu Oct 10 20:24:35 EDT 2019
On Thu, Oct 10, 2019 at 8:03 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
> 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.
Pd has void clock_delay(t_clock *x, double delaytime) exactly for this
purpose. clock_delay(x, 0) essentially queues it for the next interrupt.
This is what the disis_wiimote and pd-l2ork version of libcwiid utilizes
extensively and it requires several threads to operate as seamlessly as
possible in terms of recognizing things like the passthrough interleaved
mode between nunchuk and plus. Granted, its threaded design still needs
some form of semaphore or mutex that keeps things sane, but this can be
fairly universal since its execution is always at the end of the completed
computation (whatever that may be). This granularity is the limitation of
pd as a language since it can only process updates within the interrupt,
even if they occurred earlier during servicing of the audio output (if
any), so the aforesaid should be no worse than anything else in the pd-land.
> 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?
I suppose, although it is only as lossless as the pd interrupt allows it to
be, so on some level this is moot unless it is an audio signal thread.
> > 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>
> >> 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
> >> 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
> >> "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
> >> by sending more coins to the left inlet. (If you send coins after
> >> is finished the "vm" just passes them through.)
> >> AFAICT this lets us deterministically suspend and resume computation in
> >> 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.
> >> 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
> >> 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
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the L2Ork-dev