Menu
▾
▴
linuxsampler-devel
|
From: Benno S. <be...@ga...> - 2002-11-06 11:05:10
|
(discussion about DMIDI and GUI/Sampler communication) Hi Phil, I took a brief look at DMIDI and it looks interesting. Of course it would be very handy to add DMIDI support to LinuxSampler. Immagine several rackmount PCs running the sampler connected to a 100Mbit LAN which allows you to drive the sampler even via a Windows/Mac client (Cubase,Logic) with with a DMIDI output driver. Regarding the sampler->GUI protocol I think is is wise to use a TCP socket for this since it saves you from the hassles of handling lost packets and since on a LAN TCP transmission errors show up very rarely, I think the speed that can be achieved (for GUI purposes) is more than adequate and most of times the round-trip latency will be below 1msec. For real time messages like MIDI UDP is of course much better but I'd like it to be somewhat "safe". (eg it is not nice to hear a group of hanging notes due to a lost packet). Can DMIDI currently deal with errors ? What protocol do you use ? RTP or raw UDP ? Not sure if the paradigm of "better late than never" fits into MIDI but as said missing notes, controller msgs etc can do much more damage than late events. So I think we need a bit of redundancy when sending MIDI events. In the case you are using raw UDP, how about simply sending two identical packets for each group of events and having the host detecting and discarding the duplicates ? As said before a lost packet on a non-broken LAN happens very seldom (except in extremely congested networks but that is not the typical case of a LAN used for MIDI transmission). Thus commonsense would say me that if we send two packets instead of one the probabilty that both don't come through is very very low. ( in an uniform error distribution Pboth_packets_losts=Ppacket1_lost * Ppacket2_lost) I think this is a very interesting topic and I'd like you to share your thoughts with us. Regarding using CV I am not 100% sure about that, sure it simplifies things a bit but I think that in some cases we loose efficiency and flexibility. I'm currently designing an efficient RAM sampler object that can fit within the modular and recompilable sampler concept. (using time stamps for maximum precision and efficiency). I will post a diagram and a description in 1-2 days so that the list can comment on and correct eventual design mistakes. cheers, Benno -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it. |
|
From: Phil K. <phi...@el...> - 2002-11-06 11:55:00
|
Hi Benno, 100mb ethernet..... Oh that's so old fashioned, WiFi is better :) That's the goal of DMIDI, it allows any platform to communicate with anything. This really would allow LinuxSampler to gain a good foothold in non Linux studio's if it can be controlled from exiting applications or hardware. There's always a balance between using TCP and UDP, but there's a great deal of overlap especially when we are talking about LAN environments. I've been testing networks for a while and even on our POS 10mb LAN in work I've not dropped a packet but TCP does give you an extra level of protection. RTT's within a lan would be good enough to use TCP but IIRC it does add a small delay (0.5 ms) DMIDI uses raw UDP as RTP would only tell you how late a packet is. UDP is also supported by a wider range of languages and hardware (important for me) The only time you need protection is when you try and stream over the internet and this is where John Lazzaro has done good work. When describing ideal DMIDI networking conditions I use the analogy of audio cabling. Our target audience of non-technical musicians understand this concept well. Double sending UDP packets works quite well and doesn't seem to add much network overhead. MIDI doesn't have any protection mechanism and it works well. It may be good if people checkout SpiralSynth and DMIDI to get a taste of how it works: www.dmidi.org. Note. I get playback delays with SpiralSynth itself of 200-400ms quite often, test this by using a qwerty keyboard. The plan is to add more remote control to SSM and then update SpiralSynth later. Cheers Phil On Wed, 2002-11-06 at 13:08, Benno Senoner wrote: > (discussion about DMIDI and GUI/Sampler communication) > > Hi Phil, > I took a brief look at DMIDI and it looks interesting. > Of course it would be very handy to add DMIDI support to LinuxSampler. > Immagine several rackmount PCs running the sampler connected to a > 100Mbit LAN > which allows you to drive the sampler even via a Windows/Mac client > (Cubase,Logic) with > with a DMIDI output driver. > > Regarding the sampler->GUI protocol I think is is wise to use a > TCP socket for this since > it saves you from the hassles of handling lost packets and since on a > LAN TCP transmission errors > show up very rarely, I think the speed that can be achieved (for > GUI purposes) is more than > adequate and most of times the round-trip latency will be below 1msec. > > For real time messages like MIDI UDP is of course much better but I'd > like it to be somewhat > "safe". (eg it is not nice to hear a group of hanging notes due to a > lost packet). > > Can DMIDI currently deal with errors ? What protocol do you use ? RTP or > raw UDP ? > Not sure if the paradigm of "better late than never" fits into MIDI but > as said missing notes, > controller msgs etc can do much more damage than late events. > So I think we need a bit of redundancy when sending MIDI events. > In the case you are using raw UDP, how about simply sending two > identical packets for each > group of events and having the host detecting and discarding the > duplicates ? > As said before a lost packet on a non-broken LAN happens very seldom > (except in extremely > congested networks but that is not the typical case of a LAN used for > MIDI transmission). > Thus commonsense would say me that if we send two packets instead of one > the probabilty > that both don't come through is very very low. > ( in an uniform error distribution Pboth_packets_losts=Ppacket1_lost * > Ppacket2_lost) > > I think this is a very interesting topic and I'd like you to share your > thoughts with us. > > Regarding using CV I am not 100% sure about that, sure it simplifies > things a bit but I think > that in some cases we loose efficiency and flexibility. > > I'm currently designing an efficient RAM sampler object that can fit > within the modular and > recompilable sampler concept. (using time stamps for maximum precision > and efficiency). > I will post a diagram and a description in 1-2 days so that the list can > comment on and correct > eventual design mistakes. > > cheers, > Benno > > -- > http://linuxsampler.sourceforge.net > Building a professional grade software sampler for Linux. > Please help us designing and developing it. > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Steve H. <S.W...@ec...> - 2002-11-06 13:55:32
|
On Wed, Nov 06, 2002 at 11:47:12AM +0000, Phil Kerr wrote: > Hi Benno, > > 100mb ethernet..... Oh that's so old fashioned, WiFi is better :) Actually, wifi has a pretty high latency, try running X over it sometime, there is a detectable delay, even though the throughput is high enough. - Steve |
|
From: Steve H. <S.W...@ec...> - 2002-11-06 14:08:01
|
On Wed, Nov 06, 2002 at 02:08:07PM +0100, Benno Senoner wrote: > Regarding the sampler->GUI protocol I think is is wise to use a > TCP socket for this since > it saves you from the hassles of handling lost packets and since on a > LAN TCP transmission errors > show up very rarely, I think the speed that can be achieved (for > GUI purposes) is more than > adequate and most of times the round-trip latency will be below 1msec. I agree. I also dont think it is neccesary or desirable to define the on-the-wire protocl to the action level. Some sampler engines will have things we havn't though of, some will implement things in incompatoible ways. I think its enough to say, it will be TCP (or UDP) and maybe define a service discovery mechanism. Re. the IP MIDI thing, whats wrong with the RTP MIDI standard, that's currently in the pre-RFC stage? RTP seems more sensible that multitransmit UPD to me. > Regarding using CV I am not 100% sure about that, sure it simplifies > things a bit but I think > that in some cases we loose efficiency and flexibility. How so? We would gain flexibility, and the efficiency issue is not that simple. Using event based systems its very hard to express arbitrary modulations. NB I'm only advocating CV for the processing part of the signal path, the sample based signal generation, obviously needs to be event based. I seriously doubt there are any sample engines out there that are event based internally (for the post processing part), it would make your life very hard. In any case, if we use sub engines for each sample format, its up to each sub engine how its implemented internally. - Steve |
|
From: Steve H. <S.W...@ec...> - 2002-11-06 14:59:00
|
[putting this back on the list] On Wed, Nov 06, 2002 at 02:26:40PM +0000, Phil Kerr wrote: > The biggest difference between DMIDI and MWPP is it's networking scope. > MWPP has been optimised for Internet transmission whereas DMIDI is > optimised for LAN's and is much closer to raw MIDI. The device > identification schema also follows MIDI closer than MWPP which uses > SIP. OK, makes sense. I gues that means we should support both, and probably OSC, as that seems quite popular and has better resultion than MIDI. It is also UDP based IIRC. All incoming event protocols should be normalised in some way IMHO. > You mentioned a service discovery mechanism, do you mean some form of > application introspection that can be broadcast? This is an interesting > area I've been doing some thinking about. Any further thoughts in this > area? Yes, thats it. I've done some work in this area. There are two forms of serveice discovery, syntaic (API level) and semantic (er, harder to define ;) but we probably dont need it). There are some existing standards, eg. WSDL (web sevice description language, http://www.w3.org/TR/wsdl), but they tend to be SOAP (XML-RPC) biased, and are probably overkill for what we need unless you want to describe specific services, eg. an envelope editor. Basicly the deal is you have either a well know broker or broadcast your requirements ("I'm an Akai GUI, protocol v3.4, I want an engine"), and you get back a list of candidates. XML is your friend here. The scheme I would suggest goes something like: Broker fires up Engines reister with Broker (easy if the top level engine is also the Broker) UI starts, queries Broker Broker queries each engine in turn to find out if it can handle the UI Broker retrurns list to UI This also scales to multiple Engines on multiple machines, it just means that the Engine has to register with an external Broker. If the Engines are external, but they hold open a socket to the Broker then they can tell if it sudenly goes away (or vice versa), which helps. - Steve |
|
From: Phil K. <phi...@el...> - 2002-11-06 15:42:48
|
Thanks Steve, (note to self, press reply to all not reply ;) My idea's were similar but are lower level, more akin to ARP broadcasts. An app broadcasts the DMIDI meta-command for 'who's there' and all devices reply. The session could look something like: Enquirer -> ff:ff:00:00 Device 1 -> ff:ff:00:01 [node id] description Device 2 -> ff:ff:00:01 [node id] description The exact format hasn't been 100% defined yet but it should be close to that of above. I've some very basic code for this but it hasn't been integrated into anything fully working. Although SOAP and WSDL are good choices in themselves they are heavy and having to include XML parsers does add bloat. I'm not sure if going down the CORBA road would be good but it does work. John has started work on a coding guide to MWPP and we should be able to use his examples. Do we have access to any OSC code? -P On Wed, 2002-11-06 at 14:58, Steve Harris wrote: > [putting this back on the list] > > On Wed, Nov 06, 2002 at 02:26:40PM +0000, Phil Kerr wrote: > > The biggest difference between DMIDI and MWPP is it's networking scope. > > MWPP has been optimised for Internet transmission whereas DMIDI is > > optimised for LAN's and is much closer to raw MIDI. The device > > identification schema also follows MIDI closer than MWPP which uses > > SIP. > > OK, makes sense. I gues that means we should support both, and probably > OSC, as that seems quite popular and has better resultion than MIDI. > It is also UDP based IIRC. > > All incoming event protocols should be normalised in some way IMHO. > > > You mentioned a service discovery mechanism, do you mean some form of > > application introspection that can be broadcast? This is an interesting > > area I've been doing some thinking about. Any further thoughts in this > > area? > > Yes, thats it. I've done some work in this area. > > There are two forms of serveice discovery, syntaic (API level) and > semantic (er, harder to define ;) but we probably dont need it). > > There are some existing standards, eg. WSDL (web sevice description > language, http://www.w3.org/TR/wsdl), but they tend to be SOAP (XML-RPC) > biased, and are probably overkill for what we need unless you want to > describe specific services, eg. an envelope editor. > > Basicly the deal is you have either a well know broker or broadcast your > requirements ("I'm an Akai GUI, protocol v3.4, I want an engine"), and you > get back a list of candidates. XML is your friend here. > > The scheme I would suggest goes something like: > > Broker fires up > Engines reister with Broker (easy if the top level engine is also the Broker) > UI starts, queries Broker > Broker queries each engine in turn to find out if it can handle the UI > Broker retrurns list to UI > > This also scales to multiple Engines on multiple machines, it just means > that the Engine has to register with an external Broker. > > If the Engines are external, but they hold open a socket to the Broker > then they can tell if it sudenly goes away (or vice versa), which helps. > > - Steve > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Steve H. <S.W...@ec...> - 2002-11-06 15:58:09
|
On Wed, Nov 06, 2002 at 03:34:58PM +0000, Phil Kerr wrote: > My idea's were similar but are lower level, more akin to ARP broadcasts. I think the higher level has advantages. > Although SOAP and WSDL are good choices in themselves they are heavy and > having to include XML parsers does add bloat. I'm not sure if going > down the CORBA road would be good but it does work. Yes, I wasn't suggesting SOAP or WSDL for connection level service discovery, they are much too heavy, though that has nothing to do with XML. I dont think you can describe the overhead of an XML parser (especialy libxml) on a sampler engine as bloat. CORBA would be however. I would be nice if engines or guis could be written on any platform that can support TCPIP and XML, without requreing the use of low level DMIDI stuff. XML also removes the need for syntax descriptions and so on, you just publish a DTD or schema. > John has started work on a coding guide to MWPP and we should be able to > use his examples. Do we have access to any OSC code? Sure, the reference implementation is available, and John L. has implemented support for it in saol IIRC. The origianl reference implementation was a mess, but I think its been cleanedup and modernised since then. - Steve |
|
From: Phil K. <phi...@el...> - 2002-11-06 17:42:10
|
Both approaches have advantages. The high-level, using XML, approach gives us a far richer dataset to work with. The low-level allows for better MIDI hardware support. There's probably a cut-off point where one method is better than the other. For config data using XML has clear cross-platform advantages and XML-RPC is a lot lighter than SOAP and could serve our needs well. For real-time control DMIDI would be good as it allows hardware control and the syntax checking is minimal. This is where using XML instead of CC or SYSEX messages would be too heavy. I think it would be good if we could find a split point between what can be controlled by a GUI and what can be controlled by MIDI hardware, even though there's overlap to an extent. Cheers -P On Wed, 2002-11-06 at 15:58, Steve Harris wrote: > On Wed, Nov 06, 2002 at 03:34:58PM +0000, Phil Kerr wrote: > > My idea's were similar but are lower level, more akin to ARP broadcasts. > > I think the higher level has advantages. > > > Although SOAP and WSDL are good choices in themselves they are heavy and > > having to include XML parsers does add bloat. I'm not sure if going > > down the CORBA road would be good but it does work. > > Yes, I wasn't suggesting SOAP or WSDL for connection level service > discovery, they are much too heavy, though that has nothing to do with > XML. I dont think you can describe the overhead of an XML parser > (especialy libxml) on a sampler engine as bloat. CORBA would be however. > > I would be nice if engines or guis could be written on any platform that > can support TCPIP and XML, without requreing the use of low level DMIDI > stuff. XML also removes the need for syntax descriptions and so on, you > just publish a DTD or schema. > > > John has started work on a coding guide to MWPP and we should be able to > > use his examples. Do we have access to any OSC code? > > Sure, the reference implementation is available, and John L. has > implemented support for it in saol IIRC. The origianl reference > implementation was a mess, but I think its been cleanedup and modernised > since then. > > - Steve > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Steve H. <S.W...@ec...> - 2002-11-06 17:46:45
|
On Wed, Nov 06, 2002 at 05:34:21PM +0000, Phil Kerr wrote: > For config data using XML has clear cross-platform advantages and > XML-RPC is a lot lighter than SOAP and could serve our needs well. I was thinking of raw XML, not XML-RPC. > For real-time control DMIDI would be good as it allows hardware control > and the syntax checking is minimal. This is where using XML instead of > CC or SYSEX messages would be too heavy. Argh, yes! I think we were talking at cross purposes. I was just thinking of the service discovery phase, obviously the control protocol wants to be be binary nad lightweight. > I think it would be good if we could find a split point between what can > be controlled by a GUI and what can be controlled by MIDI hardware, even > though there's overlap to an extent. Yes, probably. - Steve |
|
From: Phil K. <phi...@el...> - 2002-11-06 20:32:27
|
Aaaah, I see :) So we have n number of engines and a GUI broadcasts a message to see what's there. Each engine reponds with config data. So, what data does the GUI need? An instance identifier. What MIDI chan. is it on. Patch details (sample info, adsr, filter, loop points). Effect details. JACK connection info. ..... Others The GUI would be greatly enhanced if it can display waveform data so there should be a mechanism of passing this from the engine. It doesn't need to be a dump of the sample data, just enough info to do editing. I think most of the other controls of the engine will be MIDI based data: notes, pitchbend, cc data. What about uploading samples from the GUI to the engine remotely? Thoughts? -P Quoting Steve Harris <S.W...@ec...>: > On Wed, Nov 06, 2002 at 05:34:21PM +0000, Phil Kerr wrote: > > For config data using XML has clear cross-platform advantages and > > XML-RPC is a lot lighter than SOAP and could serve our needs well. > > I was thinking of raw XML, not XML-RPC. > > > For real-time control DMIDI would be good as it allows hardware > control > > and the syntax checking is minimal. This is where using XML instead > of > > CC or SYSEX messages would be too heavy. > > Argh, yes! I think we were talking at cross purposes. I was just > thinking > of the service discovery phase, obviously the control protocol wants to > be > be binary nad lightweight. > > > I think it would be good if we could find a split point between what > can > > be controlled by a GUI and what can be controlled by MIDI hardware, > even > > though there's overlap to an extent. > > Yes, probably. > > - Steve > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Steve H. <S.W...@ec...> - 2002-11-06 20:52:51
|
On Wed, Nov 06, 2002 at 09:49:40 +0000, Phil Kerr wrote: > Aaaah, I see :) > > So we have n number of engines and a GUI broadcasts a message to see what's > there. Each engine reponds with config data. I was thinking there would be a broker, and that could do the selection. Broadcast is a bit problematic. Probably the only info needed would be that engine the UI is for, and what version of the UI protocol it speaks (internal to the UI<->engine connection), eg: <engine> <type>linux-akai</type> <protocol major="0" minor="1" micro="1" /> </engine> Other stuff can be done between the UI and engine privatly, other things dont need to be able to understand it. > I think most of the other controls of the engine will be MIDI based data: notes, > pitchbend, cc data. Right, but that is more of a realtime control thing, than a UI thing. The UI could use those (eg. for testing), but doesn't have to. MIDI can be received either my alsa midi, or dmidi or whatever. - Steve |
|
From: Phil K. <phi...@el...> - 2002-11-06 22:54:34
|
Quoting Steve Harris <S.W...@ec...>: > On Wed, Nov 06, 2002 at 09:49:40 +0000, Phil Kerr wrote: > > Aaaah, I see :) > > > > So we have n number of engines and a GUI broadcasts a message to see > what's > > there. Each engine reponds with config data. > > I was thinking there would be a broker, and that could do the selection. > Broadcast is a bit problematic. > > Probably the only info needed would be that engine the UI is for, and > what version of the UI protocol it speaks (internal to the UI<->engine > connection), eg: > > <engine> > <type>linux-akai</type> > <protocol major="0" minor="1" micro="1" /> > </engine> > > Other stuff can be done between the UI and engine privatly, other things > dont need to be able to understand it. > Yes, this looks good. > > I think most of the other controls of the engine will be MIDI based > data: notes, > > pitchbend, cc data. > > Right, but that is more of a realtime control thing, than a UI thing. > The > UI could use those (eg. for testing), but doesn't have to. MIDI can be > received either my alsa midi, or dmidi or whatever. It could be a mixture of both. I can alter, for example, filter setting from either the front panel or via sysex. -P > > - Steve > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Richard A. S. <rs...@bi...> - 2002-11-06 21:01:25
|
On Wed, 6 Nov 2002 17:46:34 +0000, Steve Harris wrote: > > For real-time control DMIDI would be good as it allows hardware control > > and the syntax checking is minimal. This is where using XML instead of > > CC or SYSEX messages would be too heavy. > > Argh, yes! I think we were talking at cross purposes. I was just thinking > of the service discovery phase, obviously the control protocol wants to be > be binary nad lightweight. > > > I think it would be good if we could find a split point between what can > > be controlled by a GUI and what can be controlled by MIDI hardware, even > > though there's overlap to an extent. What kind of real-time GUI control are we talking about? Perhaps I'm showing my sampler ignorance here, but seems to me that control via MIDI and control via socket are 2 sperate entities in 2 seperate worlds with very different manners of operation. So why try to handle them with the same system? If you wanted to send the engine say something like DMIDI data then shouldn't that be on a seperate socket? I'm not sure that the one-socket-do-it-all approach makes any sense. Most of the GUI stuff is all patch uploading, layering control, asignment of channels, loop points, graph setup, etc, all non-real time stuff. I suppose if you are controlling it via a software sequencer then there would be a good bit of real-time type data but I would think thats much better handled via the midi system rather than a general purose GUI control port. -- Richard A. Smith Bitworks, Inc. rs...@bi... 479.846.5777 x104 Sr. Design Engineer http://www.bitworks.com |
|
From: Phil K. <phi...@el...> - 2002-11-06 22:33:38
|
Yes. Local MIDI control using ALSA shouldn't be a problem and it may work out best to have two, or more, ports for remote control. I'm not 100% if there are any issues with contex switching in the TCP stack but I don't see that there would be too many situations where you would be hammering the GUI and control ports at the same time. -P Quoting "Richard A. Smith" <rs...@bi...>: > On Wed, 6 Nov 2002 17:46:34 +0000, Steve Harris wrote: > > > > For real-time control DMIDI would be good as it allows hardware > control > > > and the syntax checking is minimal. This is where using XML instead > of > > > CC or SYSEX messages would be too heavy. > > > > Argh, yes! I think we were talking at cross purposes. I was just > thinking > > of the service discovery phase, obviously the control protocol wants > to be > > be binary nad lightweight. > > > > > I think it would be good if we could find a split point between what > can > > > be controlled by a GUI and what can be controlled by MIDI hardware, > even > > > though there's overlap to an extent. > > What kind of real-time GUI control are we talking about? > > Perhaps I'm showing my sampler ignorance here, but seems to me that > control via MIDI and control via socket are 2 sperate entities in 2 > seperate worlds with very different manners of operation. So why try > to handle them with the same system? > > If you wanted to send the engine say something like DMIDI data then > shouldn't that be on a seperate socket? I'm not sure that the > one-socket-do-it-all approach makes any sense. Most of the GUI stuff > is all patch uploading, layering control, asignment of channels, loop > points, graph setup, etc, all non-real time stuff. > > I suppose if you are controlling it via a software sequencer then > there would be a good bit of real-time type data but I would think > thats much better handled via the midi system rather than a general > purose GUI control port. > > > -- > Richard A. Smith Bitworks, Inc. > rs...@bi... 479.846.5777 x104 > > Sr. Design Engineer http://www.bitworks.com > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Steve H. <S.W...@ec...> - 2002-11-07 09:18:23
|
On Thu, Nov 07, 2002 at 12:11:51 +0000, Phil Kerr wrote: > > > I think most of the other controls of the engine will be MIDI based > > data: notes, > > > pitchbend, cc data. > > > > Right, but that is more of a realtime control thing, than a UI thing. > > The > > UI could use those (eg. for testing), but doesn't have to. MIDI can be > > received either my alsa midi, or dmidi or whatever. > > It could be a mixture of both. I can alter, for example, filter setting from > either the front panel or via sysex. Right, but nothing stops the UI from opening a DMIDI connection to the engine as well as the UI socket. - Steve |
|
From: Phil K. <phi...@el...> - 2002-11-07 10:17:09
|
Nope, this gives us more flexibility being able to do this. -P On Thu, 2002-11-07 at 09:18, Steve Harris wrote: > On Thu, Nov 07, 2002 at 12:11:51 +0000, Phil Kerr wrote: > > > > I think most of the other controls of the engine will be MIDI based > > > data: notes, > > > > pitchbend, cc data. > > > > > > Right, but that is more of a realtime control thing, than a UI thing. > > > The > > > UI could use those (eg. for testing), but doesn't have to. MIDI can be > > > received either my alsa midi, or dmidi or whatever. > > > > It could be a mixture of both. I can alter, for example, filter setting from > > either the front panel or via sysex. > > Right, but nothing stops the UI from opening a DMIDI connection to the > engine as well as the UI socket. > > - Steve > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X