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: http://avb-list.new-synth.info (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 .. check http://www.xmos.com/published/xc-verilog-designers-application-note?ver=wp-xmos-verilog-100622.pdf 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 errordevelo...@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@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list