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