> An OSC note standard would be nice, but I don't know if it's even
possible (it's different for everyone). Service discovery and namespace
enumeration need to just make it a nonexistant problem IMO.
It would be *very* nice, if not a real pain to be without!
It strikes me that whenever OSC *does
On Fri, 2005-13-05 at 20:22 +0200, Fons Adriaensen wrote:
> On Sat, May 14, 2005 at 03:31:08AM +1000, Dave Robillard wrote:
>
> > If by you mean MIDI style channel number - dear god no. :)
> > Note numbers are debatable (but frequency is better in most cases), but
> > channel numbers definitely d
On Fri, 2005-13-05 at 11:54 +0200, Alfons Adriaensen wrote:
> 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 pr
On Sat, May 14, 2005 at 03:31:08AM +1000, Dave Robillard wrote:
> If by 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
On Fri, 2005-13-05 at 12:13 +0200, Alfons Adriaensen wrote:
> On Fri, May 13, 2005 at 10:16:41AM +0200, Albert Graef wrote:
>
> > /set
> >
> > ...
> >
> > The disadvantage of this fairly basic scheme is of course that the
> > client has to dispatch the voices himself.
>
> It's possible t
On Fri, May 13, 2005 at 10:16:41AM +0200, Albert Graef wrote:
> /set
>
> ...
>
> The disadvantage of this fairly basic scheme is of course that the
> client has to dispatch the voices himself.
It's possible to have the best of both worlds and remain close
to midi, something like:
/note_
On Fri, May 13, 2005 at 02:18:38AM +0100, Steve Harris wrote:
> My preferred form would be something like
>
> /std_prefix/inst_name/base_freq f
> /std_prefix/inst_name/note_on iff
> /std_prefix/inst_name/note_off if
What's the param for ?
> But seen as I've never written an OSC syn
Steve Harris wrote:
My preferred form would be something like
/std_prefix/inst_name/base_freq f
/std_prefix/inst_name/note_on iff
/std_prefix/inst_name/note_off if
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
On Thu, May 12, 2005 at 05:55:05 -0400, Jesse Chappell wrote:
> Fons Adriaensen wrote on Thu, 12-May-2005:
>
> > 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 ea
On Thu, May 12, 2005 at 07:52:22 +0200, Fons Adriaensen wrote:
> On Fri, May 13, 2005 at 02:52:44AM +1000, Dave Robillard wrote:
>
> > FWIW, Om's OSC documentation (in both directions) is also online:
> >
> > http://www.nongnu.org/om-synth/engine_osc_namespace.html
> > http://www.nongnu.org/om-sy
On Thu, May 12, 2005 at 05:22:43 +0200, Alfons Adriaensen wrote:
> One thing I forgot to mention regarding /addclient : the response
> to this will include a client ID (integer) that is a required
> parameter to all polled requests for information, such as e.g.
> the list of stops. This ID identif
Fons Adriaensen wrote on Thu, 12-May-2005:
> 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, h
Dave Robillard wrote:
On Thu, 2005-12-05 at 17:54 +0200, stefan kersten wrote:
On Thu, May 12, 2005 at 05:22:43PM +0200, Alfons Adriaensen wrote:
One thing I forgot to mention regarding /addclient : the response
to this will include a client ID (integer) that is a required
parameter to all polled
On Fri, May 13, 2005 at 02:52:44AM +1000, Dave Robillard wrote:
> FWIW, Om's OSC documentation (in both directions) is also online:
>
> http://www.nongnu.org/om-synth/engine_osc_namespace.html
> http://www.nongnu.org/om-synth/client_osc_namespace.html
Thanks, some more reference material to read
On Thu, May 12, 2005 at 12:39:21PM -0400, Jesse Chappell wrote:
> 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.
[ looks at the in
On Thu, May 12, 2005 at 06:12:11PM +0200, Alfons Adriaensen wrote:
> Would there be a significant overhead in using recvfrom() and sendto()
> instead of having a 'connected' socket for each client ?
apart from the additional copying of the return address
there should be no real difference in perfo
On Thu, 2005-12-05 at 12:39 -0400, Jesse Chappell wrote:
> Alfons Adriaensen wrote on Thu, 12-May-2005:
>
> > On Thu, May 12, 2005 at 11:40:51AM -0400, Jesse Chappell wrote:
> >
> > > No, i mean the arguments the engine will use in the callbacks
> > > are conventionally specified in the OSC "
On Thu, 2005-12-05 at 17:54 +0200, stefan kersten wrote:
> On Thu, May 12, 2005 at 05:22:43PM +0200, Alfons Adriaensen wrote:
> > One thing I forgot to mention regarding /addclient : the response
> > to this will include a client ID (integer) that is a required
> > parameter to all polled requests
Alfons Adriaensen wrote on Thu, 12-May-2005:
> On Thu, May 12, 2005 at 11:40:51AM -0400, Jesse Chappell wrote:
>
> > No, i mean the arguments the engine will use in the callbacks
> > are conventionally specified in the OSC "API" for these comms.
>
> Sorry but this still escapes me... Could
On Thu, May 12, 2005 at 05:54:15PM +0200, stefan kersten wrote:
> On Thu, May 12, 2005 at 05:22:43PM +0200, Alfons Adriaensen wrote:
> > One thing I forgot to mention regarding /addclient : the response
> > to this will include a client ID (integer) that is a required
> > parameter to all polled
On Thu, May 12, 2005 at 11:40:51AM -0400, Jesse Chappell wrote:
> No, i mean the arguments the engine will use in the callbacks
> are conventionally specified in the OSC "API" for these comms.
Sorry but this still escapes me... Could you give an example ?
--
FA
On Thu, May 12, 2005 at 05:22:43PM +0200, Alfons Adriaensen wrote:
> One thing I forgot to mention regarding /addclient : the response
> to this will include a client ID (integer) that is a required
> parameter to all polled requests for information, such as e.g.
> the list of stops. This ID ident
Alfons Adriaensen wrote on Thu, 12-May-2005:
> > values that continuously change. My register calls usually take
> > a URI and an osc path that will be used for the callback message
> > (with predetermined arguments).
>
> Do you mean the client specifies the format of the reply messages
> i
On Thu, May 12, 2005 at 11:01:15AM -0400, Jesse Chappell wrote:
> Have you considered process separation for the engine and the
> "local GUI" ? At least an option to run aeolus with no gui/x.
Not process separation, but the local user interface will be
a configuration and comannd line option: --
Alfons Adriaensen wrote on Thu, 12-May-2005:
> - There will be one UDP server socket. This socket is left
> unconnected, and will receive OSC commands from any source.
> These commands give you complete control over most aspects
> of Aeolus (excluding the stop definition editor which wil
Hello all,
I'm planning the OSC-fication of Aeolus, and would like to have
some comments / feedback on the current ideas (they could well
be braindead, in which case you are kindly requested to say so).
The setup I have in mind is as follows:
- There will be one UDP server socket. This socket i
26 matches
Mail list logo
