Linux vessel [was: L Re: [Lua-av] Hi there]

[Graham Wakefield]

On Dec 16, 2007, at 4:25 AM, Frank Barknecht wrote:

> Hallo,
>
> so, my bug squashing sessions have been quite sucessful so far and now
> I've got a running vessel-interpreter for Linux here. It's very
> satisfying to be able to hear the Lua examples.

Wonderful!

> My portaudio crashes
> were related to a bug in Portaudio's ALSA backend, where I could make
> a workaround, which made the vessel-"tool"  finally run.

Did you let the PA guys know?

> Changing
> "argv * char"  to "argv ** char" in tool/main.cpp and using "filepath"
> instead of "scriptpath"
oops
> even lets me run different files supplied as
> command line options, hooray. ;) For compiling I use scons with the
> SConstruct file as posted instead of bothering with a Makefile.

Great, well I'm glad it works.  Next obvious thing would be to add  
command line access to the interpreter...

>
> Graham Wakefield hat gesagt: // Graham Wakefield wrote:
>
>> On Dec 13, 2007, at 11:57 AM, Frank Barknecht wrote:
>>>
>>> I've actually read your fine thesis yesterday!
>>
>> Oh ok, I hope it made sense! Actually, I'd welcome any comments.
>
> It made a lot of sense, and I agree with a lot of what you wrote,
> especially with one of your main points: I never relly liked
> having to write music/sound code in domain specific languages. At
> least not full programs (it's okay for specific tasks like writing DSP
> algorithms in Faust or so.)
>
> I believe, in your short presentation of the Max family (sect. 2.1)
> some points are rather specific to Max/MSP and aren't valid for Pd. In
> Pd, messages actually can be scheduled with (sub)sample accuracy.

That is interesting - I wasn't aware of that!

> For
> one, the speed of message passing is not related to the audio block
> size in Pd. Unlike in Max, you don't get worse response times with
> messages when you run a bigger block size: messages are always passed
> along every 64 samples regardless of block size.

In fact in Max it really depends upon how the scheduler is  
configured, there are different ways ('overdrive', 'audio interrupt'  
and so on)... which only makes it harder to debug threading issues  
BTW... it is possible to get more accurate messaging, but I don't  
think it can be sample accurate.  PD certainly sounds to be better in  
this regard.

I wonder how many PD objects actually make use of the clock-delays,  
and how many stick to the 64-sample quantization?

> It probably would make sense to let the vessel Pd object deal with
> these clock-delayed messages correctly right from the start, though
> this requires some more work in the code.

Most definitely.  It sounds like it might be easier to get it working  
in PD than Max anyway.  It should be a matter of launching them as  
new coroutines with the clock delay.  For example in  
luabeta~.dsp.cpp, around line 295 of LuaBeta::doDsp(), where atoms  
sent as 'call' messages are picked up from the message buffer and  
turned into new coroutines:

vessel->go(L, vessel->now);

Simply adding the PD message clock delay to vessel->now should  
achieve sample-accurate messaging from PD to lua~.

I wonder if the developer deals with threading between the message  
passing and the dsp functions differently in PD.  That was my biggest  
headache in Max.  The Lua state absolutely must be referenced only in  
a single thread.
grrr waaa
www.grahamwakefield.net