Alfons Adriaensen wrote on Thu, 12-May-2005: No, i mean the arguments the engine will use in the callbacks are conventionally specified in the OSC "API" for these comms. Right now, all my callback related stuff uses the URI of the callback as the ID, since I was passing it around anyway. An ID would probably be better. jlc

Alfons Adriaensen wrote on Thu, 12-May-2005: OK, check out http://essej.net/sooperlooper/doc_osc.html and look at the Get parameters section, and the register for control changes section. Sorry for the confusing terminology, it's really pretty simple. jlc

On Fri, May 13, 2005 at 02:52:44AM +1000, Dave Robillard wrote: Thanks, some more reference material to read ! On MIDI, the note commands come on a 'channel' and this is handled in Aeolus as follows: channels -> [MIDI matrix] -> keyboards -> [coupler matrix] -> divisions Would something like the MIDI channel matrix be useful for OSC ? My current view is that OSC note commands should refer directly to the keyboards. Something like /notes_on ,iiii... <keyb> <note> <note> <note> ... -- FA

Steve Harris wrote: Hmm, what would the note-id be? And the octave is the log_2 of the frequency, right? Occam also seems to be a reasonable way for a 1-1 OSC-MIDI mapping, thanks for the link. (But is that what we actually want in OSC?) At least for modular synthesizers I'd guess that a standard way of communicating notes would be a message to set the parameters of a synth voice, something like this: /set <voice> <gate> <freq> <gain> <voice> would be the identifier of the voice to play, <gate> would be 1 to start playing the note (trigger the attack) and 0 to stop it (trigger the release), <freq> would be the frequency in some convenient unit (usually either Hz, octaves, semitones or cent) and <gain> the amplification (velocity, if you prefer). In many synths you would also be able to modify each of these parameters (and probably some more) individually, while the note is already playing. In the case of Aeolus the <freq> parameter could just be a MIDI note number, as it cannot play arbitrary frequencies "on the fly". The disadvantage of this fairly basic scheme is of course that the client has to dispatch the voices himself. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikwissenschaft.uni-mainz.de/~ag

On Fri, 2005-13-05 at 12:13 +0200, Alfons Adriaensen wrote: If by <channel> you mean MIDI style channel number - dear god no. :) Note numbers are debatable (but frequency is better in most cases), but channel numbers definitely don't belong in OSC. Maybe an open-ended string identifier (which could represent a channel, a patch, a certain synth... whatever) There's no need to have confusing overloading with <voice> being zero or non-zero - just make different commands. Have one note on command to allocate the most appropriate voice (MIDI style), and one to start a note on a specific voice. In Om I've made seperate commands for global or voice-specific controls, and it works great. Ability to control individual voices specifically is one of the things I love about OSC. Death to MIDI. :) -DR-

On Fri, 2005-13-05 at 20:22 +0200, Fons Adriaensen wrote: Well, for the clients it's there because there's no particular reason a client can't be talking to numerous apps at once, so having a prefix for each app's incoming messages is necessary. For the engine, I didn't really have any particular reason. I figured maybe it would prove useful down the road to separate things. Better safe than sorry.. -DR-

On Fri, May 13, 2005 at 02:18:38AM +0100, Steve Harris wrote: What's the <octave> param for ? :-) I'm sure you could write a toy synth in less than an hour :-). I'm not even sure a hard standard would be a good thing. One of my gripes with midi has always been that it imposes a keyboard-centric model and worse, the 'voice == note' convention, on all types of instruments (and also on sequencers, note editors, etc.). Any form of standard that gets accepted by a majority will probably have the same problems, for the simple reason that this model is now widely used, and deviating from it (which will add complexity) is in the interest of only a minority of users. For an organ, velocity makes no sense, but OTOH key action need not be binary: on an instrument with mechanical action you can press a key halfway and get very weird results. IIRC some contemporary composers have used this. I've not yet made up my mind if the /note_on format of Aeolus will support this, but ideally it should. Another open question is if I will use liblo or not. I have some problems with it, and these are not related to the quality of the code, but to how it is structured. Like e.g. many GUI toolsets, liblo provides an easy to use integrated solution that will work in most cases. It is exactly that integration that gets in the way if you want to use it in a more complex situation. As it is, liblo will trigger events on its own built-in timer. This is not what you actually need in a synth. When processing an audio period, you want the events that are relevant to that period, taking into account latency and processing delays. In other words, you want events not in real time, but ahead of it, and 'on demand'. This wouild require an interface like e.g. Event_id get_event (Event_t **event, OSC_time_t limit) which will give you a pointer to the next event (if any) that comes before 'limit'. The Event_t should include the timestamp if any, so you can place the event exactly on the nearest sample if that's what you want. You should then have to choice to deal with the event yourself, or otherwise call int process_event (Event_id id) that will do the path and wildcard matching, the registered callbacks, etc., and finally void event_done (Event_id id) that signals to liblo that it can now release any resources related to the event (adding this call allow a zero-copy implementation inside liblo). These three calls should be synchronous, non blocking, and be able to execute in the context of any calling thread. If you would provide this sort of interface, it would still be possible to also provide a thread that, when optionally started by the user, would reproduce the current behaviour, soo nothing need be lost. -- FA

On Thu, May 12, 2005 at 12:39:21PM -0400, Jesse Chappell wrote: [ looks at the indicated page ] Ok, I grok it now, thanks for the reference (and it _is_ simple :-) You allow the client to request monitoring for each individual parameter individually. This makes sense of course if the parameters refer to dynamic objects, as the loops in SL. For Aeolus, the set of things to be monitored would be fixed, and I imagine a client will want them all, and can be assumed to know the formats. You also allow the client to include a return address and OSC path with each request. I have my doubts about the first: it allows the client to use a different address for each call, and this could create significant overhead for the server, having to lookup the hostnames. The OSC return path probably makes sense in a dynamic environment as SL. I'm now thinking of having /addclient ,ss host:port prefix where prefix would be string, e.g. /aeolus, that gets prepended to all asynchronous update messages sent to this client, and to allow a return OSC path parameter for information requests. Thanks for your help ! -- FA

On Thu, May 12, 2005 at 05:55:05 -0400, Jesse Chappell wrote: Nope, I'm fixing it at the moment. It also doesnt seem to endianise characters currectly on OSX (testlo fails at testlo.c:575), and I'm sure I've seen that before and been sent a patch, but I'm damned if I can remember what I did with it. There source address stuff doesnt work 100% under linux either, there seems to be some problem when IPV6 is involved, in some cases. - Steve

On Thu, May 12, 2005 at 05:54:15PM +0200, stefan kersten wrote: Yes, that would work, thanks for the hint. While this would allow the server to handle info requests in a stateless way without having to refer to a list of registered clients, registation would still be necessary to allow broadcasting asynchronous events to all clients. Would there be a significant overhead in using recvfrom() and sendto() instead of having a 'connected' socket for each client ? -- FA

On Thu, 2005-12-05 at 17:54 +0200, stefan kersten wrote: I allow either method in Om. Using the client address does work usually, but there seems to be a bug in liblo (or below) where the source network address is garbled, that I havn't been able to figure out yet... allowing the user to explicitly set the address allows working around this and other networking oddities. -DR-

On Thu, May 12, 2005 at 05:22:43 +0200, Alfons Adriaensen wrote: You can use the (source addess, port) combination. I've had some difficulty in making that work reliably with IPV6 in the mix, but I'm sure its a case of error lies between screen and keyboard. - Steve