Hi, sorry for the late response. i'm back from the conference at Edinburgh now...
At Wed, 30 Jul 2003 23:50:51 +0200, Nicola Orru' wrote: > > > > If it is possible, can you guys settle details about linker communication > > > (and probably finish it)? We can integrate both projects then. > > > > I didn't know about Peter's ld10k1 existence, but it seems to be what I thought > > initially of emufxtool, before starting to improve the assembly/disassembly core > > and the file format. > > > > I think it is a good idea, at least there will not duplicated code and, if I > > understand correctly, emufxtool might use ld10k1 as a "backend" to load patches > > onto the DSP. > > > > I am just downloading ld10k1 from sf. Will take more than a look at that. > > I took a look at ld10k1/lo10k1. Its architecture is well thought and > offers lots of possibilities. > > I can remove from emufxtool the "direct" access to the driver by > IOCTL and use the pipe to communicate to ld10k1 server. Before doing > that, maybe we should define well the "communication protocol" between > clients and server, as suggested by Jaroslav. > > This system solves also the problem of multiple patch loading and > code relocation, which my emufxtool solves at compile time (to use > more than one patch you have to compile and load them as a whole). The > same method could be used by the disassembler code to fetch DSP > content (or loader server-side DSP "images"). yep, this sounds nice. we can add a start-up script for this as well as the auto-loading of soundfonts. (/etc/alsa.d/emu10k1 is started from alsasound init script.) > The next step could be a MIDI based loader, that allows you to > store/fetch patches using SYSEX messages sent to /dev/sequencer or > alsa midi virtual ports, or anything else (a new device that replaces > the pipe?), maybe requiring some work on the modules... (Not a choice > I can make, anyway...) i don't think it's a way to go although it's doable. once if we have a good patch manager daemon, we should concentrate on it for the job. the midi effects can be managed by it eventually. > I ignore if Peter Zubaj can receive this message, but I think it > would be a good idea if we merged our projects into a single one ( : > ). yes, definitely. > A good start may be the definition of the "protocol" above. > The protocol can be "message based", each "message" may be defined, > for instance, by primitive types and surrounded by a header/footer > standard pair (containing a message id, the length of the message, and > something like a checksum to avoid "garbage"). > > Client and server "speak" through a sequence of "Request"/"Response" > message pairs, usually initiated and closed by the client. > > I.E. Message: SET PATCH > > Offset Length (in bytes) Type Value > 0 2 unsigned short (*) 0004 (ID_SET_PATCH) > 2 4 unsigned (*) total length of message > 6 30 character string name of the patch > 36 2 unsigned short (*) number of DSP instr. > .... > length+36 4 unsigned checksum > > (*) endianness to be defined > > and so on... the idea looks nice. it's a standard way to do such a work in the client/server system. is the development going on now? Takashi ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
