[PD] Layered Signal Processing and Transport Architecture

errordeveloper at gmail.com errordeveloper at gmail.com
Thu Aug 5 00:54:07 CEST 2010

On Wed, Aug 04, 2010 at 07:35:38PM +0200, Christoph Kuhr wrote:
> Hi,
> im working on a digital mixing desk, based on open source ideas in linux.
> Your idea seems really interesting!
> The desk shall have channelstrips with encoders for every gate, compressor, 
> eq and some other parameters Sending MIDI/OSC.

i have a dream to build a digital console!
after i first seen the Midas ones.. before i was more trying to figure
out anologue electronics, but now i can see digital is really my area :)

hm .. would you be interested in helping me with protocol implementation
that is kind of based on OSC, but have quite different syntax and semantics.
i have started a draft proposal, it is called ACMP -
Advanced Control and Monitoring Protocol.

I can send you more detail off-list.
so far i had been puting together all the ideas in a slides/presentation format,
also started prototyping it with Tcl and tclpd ..but stucked ATM :(

are you based in Germany?

also ..are you interested in Ethernet AVB?
i have just setup a mailing list on nabble.com:
(hope you DNS server will resolve it when you read this mail,
because i have updated the record just earlier on today)

> Im going to develop an altera cyclone 3 FPGA with a pd engine and netjack 
> interface as DSP.

hm ..that's interesting ..what CPU core architecture are you going to run PD on?
with hardfloat?
i can imagine you are looking at implementing hardware routing and
mixing and use pd for filters, dynamics and effects ..right?

..BTW, have you heared of XMOS devices?

i am quite facinated by how and what you can do on them ..
and other docs @ http://www.xmos.com/support/documentation
also they got some good videos ..

i hope to get my hands on some of their dev-kits soonish!

btw, why did you chose PD? so anyone can edit patches?

> So i dont have concret ideas on your post yet, but i feel, theres could be 
> many things to cooperate!
nice to hear that!
> I would like to hear even more details!
yeah, i'll try to send you a brief explanation of ACMP,
but the Layered Signal Processing and Transport Arch. is still in flux..

> Perhaps this topic is good for linux audio list?

yeah ..hm, i submited this to alsa-devel,
but they seem to want code really, not just a crappy abstractions/ideas
(that's kindda reasonable)
> Greets
> Ck
> Am 31.07.2010 um 04:12 schrieb errordeveloper at gmail.com:
>> Sorry for being a little bit off-topic,
>> but I would like here from everyone on this list as well as Miller
>> himself, because MAX used to run on a DSP core (according to Wikipedia)
>> This the message that i have posted to alsa-devel list yesturday:
>> I have a proposal for this Layered Model,
>> which would allow implementation of new audio interfaces with DSP cores,
>> with cross-platform compatibility and audio networking in mind.
>> it would be a sort of OSI for signal processing, but with some extra
>> stuff to it, such as a common language (library) for hardware
>> programming.
>> it's not to replace ALSA, but just to bring a different approach for
>> design engineers of professional audio applications.
>> we all know that these days a lot manufactuares chose Linux
>> for their Mixing Consoles (such as Midas, Lawo, Calrec and others),
>> also other products use Linux, but there might be only a few who use
>> ALSA (as far as i could find out there rather NONE in pro-audio Linux
>> devices).
>> Linux runs on devices such as Blackfin and OMAP, which have DSP cores,
>> but the interface is device-specific, hence low-level.
>> ALSA had been designed for conventional sound-cards (largely) also there
>> drivers for RME, DigiGram and other pro-interfaces,
>> but the hardware is still proprietary and it isn't quite flexible.
>> The idea is to bring new concepts to the world, well not 100% new,
>> but new in a way. One of these would be to implement an "open-source"
>> audio processor interface of a kind.
>> It would have configurable channel strips with (multi-band EQ and
>> dynamics).
>> Another motivating factor is upcomming completition of AVB ethernet
>> standard from IETF/IEEE, there had been no publicaly avaliable code
>> for this, nor i could find any discussions of how it could be
>> implemented in Linux. However i have contact with a professor Richard
>> Foss from Rhodes University, and there they have implemented a library
>> and packet generator for AVB, though they haven't yet published this
>> code.
>> There also hasn't heppend any wide adoption of OSC, and may be OSC is
>> not that great? I am currently working on "Control and Monitoring
>> Protocol" which could take part in this architercture on it's TOP Layer.
>> The fallowing are the ABSTRACTION layers that i have thought being most
>> general:
>> ~>> Control, Monitoring and Information (CMI)
>>    ACMP (above mentioned above, it's kind of OSC-based)
>>    or AES-x170 (both can fit together)
>>    also OSC ..or even MIDI
>>    but ACMP is more general, it should be good for lighting and
>>    other controll applications ..
>>        here is the place for GUI interfaces,
>>                hardware controllers,
>>                control surfaces ...etc
>> ~>> Signal Processing Subsystem (SPS)
>>    ~>> Core Signal Bus (CSB) : our inter-connect
>>        it has one common clock
>>        one or more control ports
>>        and one or more signal ports
>>        (a port can be input, output, or both)
>>            the control ports are exposed to CMI layer
>>            the signal prorts can be:
>>                    bridged (over Ethernet (i.e.  AVB), USB or FireWire)
>>                    interfaced (to say I2S, AES/EBU, AES-50 ..MADI, ADAT)
>>                    or streamed to a codec or
>>                    uncompressed file dumping
>>                Let's call it an Port Exposure Layer
>>    ~>> Core Signal Elements (CSE)
>>        the main abstraction for this is
>>        library (our cross-platform API)
>>        compiler (to produce platform dependent code)
>>        interpreter (to configure and glue the blocks)
>> ~>> General Purpose Operating System
>>    Of course it is still there ..it could be on a remote machine
>>    or anything ..and it could be everywhere around,
>>    even General Purpose CPU could be a fall-back option
>>    ..well, this is all about abstraction after all :)
>> This is with parallel audio clustering applications
>> and distributed chain processing in mind.
>> Looking forward to here some discussion,
>> I would like to set up a wiki and discusion list for this!
>> Regards,
>> -- 
>> Ilya Dmitrichenko
>> Илья Дмитриченко
>> email: errordeveloper at gmail.com
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> http://lists.puredata.info/listinfo/pd-list
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list