[L2Ork-dev] coin-operated scripting language

[Ivica Bukvic]

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? 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).

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20191010/fa28cc7f/attachment.html>