Re: emufxtool, formerly ld10k1

[Takashi Iwai <tiwai@suse.de>]

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