31 Aug
2004
31 Aug
'04
8:59 a.m.
Hi all,
Ok, so I'm playing with osc (currently doing gui->app communication with it)
but all my individual apps still talk midi between them. This is quite
cumbersome, as I want to start having lots of controls that midi doesn't
support - and I don't really "think" in midi these days anyway.
Is there a case now to ditch midi support and go with osc for everything? I
see midi messages are a type within osc anyway - is it fairly straight forward
to be backwards compatible this way?
cheers,
dave
31 Aug
31 Aug
11:45 a.m.
On Tue, Aug 31, 2004 at 11:43:16AM +0100, Dave Griffiths wrote:
Hi all,
Ok, so I'm playing with osc (currently doing gui->app communication with it)
but all my individual apps still talk midi between them. This is quite
cumbersome, as I want to start having lots of controls that midi doesn't
support - and I don't really "think" in midi these days anyway.
Is there a case now to ditch midi support and go with osc for everything? I
see midi messages are a type within osc anyway - is it fairly straight forward
to be backwards compatible this way?
Yes, though the 'm' type is quite limited, its an address byte (MIDI port
number or something) and 3 bytes of MIDI-ness.
No good for SysEx or anything like that and you have to normalise running
status. Good enough for notes, CC's and such though.
The obvious problem you're likly to hit is that you still need to speak
alsa-sequencer or something in order to get events from controllers. You
can go pure-OSC by accepting OSC 'm' types or occam format OSC messages
and writing a simple, external and resuable MIDI->OSC converter.
http://www.mat.ucsb.edu/~c.ramakr/illposed/occam.html
BTW, if you have reasonable OSC covereage I'd be very interested in
compatibility tests between whatever you're using and liblo.
- Steve
12:05 p.m.
On Tue, 31 Aug 2004 14:28:50 +0100, Steve Harris wrote
On Tue, Aug 31, 2004 at 11:43:16AM +0100, Dave
Griffiths wrote:
That's probably enough for me.
Hi all,
Ok, so I'm playing with osc (currently doing gui->app communication with it)
but all my individual apps still talk midi between them. This is quite
cumbersome, as I want to start having lots of controls that midi doesn't
support - and I don't really "think" in midi these days anyway.
Is there a case now to ditch midi support and go with osc for everything? I
see midi messages are a type within osc anyway - is it fairly straight forward
to be backwards compatible this way?
Yes, though the 'm' type is quite limited, its an address byte (MIDI
port number or something) and 3 bytes of MIDI-ness.
No good for SysEx or anything like that and you have to normalise running
status. Good enough for notes, CC's and such though. The obvious problem you're likly to hit is that
you still need to speak
alsa-sequencer or something in order to get events from controllers.
You can go pure-OSC by accepting OSC 'm' types or occam format OSC messages
and writing a simple, external and resuable MIDI->OSC converter.
http://www.mat.ucsb.edu/~c.ramakr/illposed/occam.html
Might well have a go at this for hardware midi control. For OSC->MIDI though,
the only thing I might have a go at controlling that isn't my own software at
this point is supercollider, and that talks OSC anyway.
BTW, if you have reasonable OSC covereage I'd be
very interested in
compatibility tests between whatever you're using and liblo.
Very early days, I've only implemented simple messages so far - but I'm using
liblo for my server and some python I've nicked for the client
http://cvs.sourceforge.net/viewcvs.py/pure-data/supercollider/python/OSC.py
Seems flawless so far though, and liblo's got a nice clean api.
cheers
dave
1:18 p.m.
On Tue, Aug 31, 2004 at 02:48:46PM +0100, Dave Griffiths wrote:
Ah, OK. Well thats one more test, I tested liblo against the original C
implementaion when I started it, and after that against itsself, but I get
nervous about self tested software. I was never sure the old C library was
doing what its supposed to though, couldn't get it to build on a modern
machine, and the only binaries I had were 4 or 5 years old :)
I like the OO-in-C style of programming, its pretty much the best of both
worlds IMHO. C syntax, but no C++ 'features'.
- Steve
BTW, if you
have reasonable OSC covereage I'd be very interested in
compatibility tests between whatever you're using and liblo.
Very early days, I've only implemented simple messages so far - but I'm using
liblo for my server and some python I've nicked for the client
http://cvs.sourceforge.net/viewcvs.py/pure-data/supercollider/python/OSC.py
Seems flawless so far though, and liblo's got a nice clean api.
2:08 p.m.
On Tue, 31 Aug 2004 16:02:43 +0100, Steve Harris wrote
On Tue, Aug 31, 2004 at 02:48:46PM +0100, Dave
Griffiths wrote:
Ah, OK. Well thats one more test, I tested liblo against the
original C implementaion when I started it, and after that against
itsself, but I get nervous about self tested software. I was never
sure the old C library was doing what its supposed to though,
couldn't get it to build on a modern machine, and the only binaries
I had were 4 or 5 years old :)
Well, everyone seems to be using liblo :)
BTW, if
you have reasonable OSC covereage I'd be very interested in
compatibility tests between whatever you're using and liblo.
Very early days, I've only implemented simple messages so far - but I'm using
liblo for my server and some python I've nicked for the client
http://cvs.sourceforge.net/viewcvs.py/pure-data/supercollider/python/OSC.py
Seems flawless so far though, and liblo's got a nice clean api. I like the OO-in-C style of programming, its pretty
much the best of
both worlds IMHO. C syntax, but no C++ 'features'.
Not mention the lack of a maze of twisty ABI's...
Just a quick side issue, I'm doing a lot of message passing - in and out of
OSC, and then through my own realtime fifo IPC layer thingy into the audio
thread of my application. Are there any standard libraries or ways of doing
this all in one go? I guess the last step is very application dependant...
dave
3:31 p.m.
At Tue, 31 Aug 2004 16:02:43 +0100,
Steve Harris wrote:
I like the OO-in-C style of programming, its pretty much the best of both
worlds IMHO. C syntax, but no C++ 'features'.
Seriously. You can easily do Real OOP in C; the only thing it lacks
is syntactic sugar. I wish there was a real C++, as in a C that has
just had a few minor, incremental improvements made to it. C++ may
have a lot in common with C in a technical sense, but the mentality it
represents is almost completely orthogonal. (And yes, you can write C
style in C++, but then, why not just use C?)
The D programming language looks very promising in this regard, but
its newsgroup faces a daily battle with people who seem more
interested in creating a religion than a tool. Now that I think about
it, that struggle seems to be a recurring theme in the world of
programming languages at large.
--Pete
<http://www.gazuga.net>
"Nothing great was ever achieved by being realistic!" --Tom Venuto
4:03 p.m.
On Tue, 31 Aug 2004 13:15:24 -0400, Pete Bessman wrote
At Tue, 31 Aug 2004 16:02:43 +0100,
Steve Harris wrote:
Getting off topic here, but there's a little more to it than that. 1 Syntactic
sugared implementation is much much more preferable to 101 conventions for
doing OOP with void pointers.
Things like typesafety, getting rid of macros in favour of inline functions.
The STL is another real reason to use C++ - the closest we have to a standard
for that sort of stuff. UML etc... There are a lot of very practical reasons
for using C++.
I like the OO-in-C style of programming, its pretty much the best of both
worlds IMHO. C syntax, but no C++ 'features'.
Seriously. You can easily do Real OOP in C; the only thing it lacks
is syntactic sugar. I wish there was a real C++, as in a C that has
just had a few minor, incremental improvements made to it. C++ may
have a lot in common with C in a technical sense, but the mentality
it represents is almost completely orthogonal. (And yes, you can
write C style in C++, but then, why not just use C?) The D programming language looks very promising in
this regard
The best thing I've seen about D is that it removes the C preprocessor - at
last! :)
cheers,
dave
5 p.m.
Getting off topic here, but there's a little more
to it than that. 1
Syntactic sugared implementation is much much more preferable to 101
conventions for doing OOP with void pointers.
Things like typesafety, getting rid of macros in favour of inline
functions. The STL is another real reason to use C++ - the closest we have
to a standard for that sort of stuff. UML etc... There are a lot of very
practical reasons for using C++.
Ahhh, I fear an outbreak of the unstoppable language zealot virus is imminent!
Once it gets airborne nothing can stop it!
Ahh, it's probably already to late... I can hear the sound of eager fingers
tapping on keyboards... save yourselves!!
;-)
/Robert
--
http://spamatica.se/music/
5 p.m.
On Tue, 2004-08-31 at 09:28, Steve Harris wrote:
The obvious problem you're likly to hit is that
you still need to speak
alsa-sequencer or something in order to get events from controllers. You
can go pure-OSC by accepting OSC 'm' types or occam format OSC messages
and writing a simple, external and resuable MIDI->OSC converter.
http://www.mat.ucsb.edu/~c.ramakr/illposed/occam.html
I was wondering about this the other day - is there no OSC 'standard'
for how to declare note-ons, offs, etc?
If OSC really is to become a MIDI replacement, there's needs to be an
explicitly defined standard that says "this is how a note is triggered"
IMO. Then we can start making fun things like OSC sequencers...
-DR-
5:19 p.m.
On Tue, 2004-08-31 at 14:44, Robert Jonsson wrote:
I can't say I've ever actually come across a C++ "zealot".. most seem
to
have an opinion similar to mine:
C++ sucks.
However, it sucks less than anything else I could use to do audio
development on linux right now.
-DR-
Getting off
topic here, but there's a little more to it than that. 1
Syntactic sugared implementation is much much more preferable to 101
conventions for doing OOP with void pointers.
Things like typesafety, getting rid of macros in favour of inline
functions. The STL is another real reason to use C++ - the closest we have
to a standard for that sort of stuff. UML etc... There are a lot of very
practical reasons for using C++.
Ahhh, I fear an outbreak of the unstoppable language zealot virus is imminent!
Once it gets airborne nothing can stop it!
Ahh, it's probably already to late... I can hear the sound of eager fingers
tapping on keyboards... save yourselves!! 
6:02 p.m.
On Tue, Aug 31, 2004 at 02:46:13PM -0400, Dave Robillard wrote:
I was wondering about this the other day - is there no
OSC 'standard'
for how to declare note-ons, offs, etc?
If OSC really is to become a MIDI replacement, there's needs to be an
explicitly defined standard that says "this is how a note is triggered"
AFAIK in the beginning it was never meant as a midi replacement, but
should -in opposite to midi- not make any assumptions on the musical
meaning of the data being sent. especially in the field of new music
or sound art, MIDI is next to completely irrelevant as carrier for
musical data (but is still used for control data like sensor stuff
etc, since you can build such a thing with a small pic uC).
however, an "official" way of encapsulating midi in osc would maybe
push especially some commercial developers to osc, but i guess the
CNMAT folks don't want to have it in their official spec.
bests,
martin
1 Sep
1 Sep
6:49 a.m.
On Tue, 31 Aug 2004 15:04:48 -0400, Dave Robillard wrote
I agree, I didn't mean to come across as a zealot :)
dave
On Tue, 2004-08-31 at 14:44, Robert Jonsson wrote:
> > Getting off topic here, but there's a little more to it than that. 1
> > Syntactic sugared implementation is much much more preferable to 101
> > conventions for doing OOP with void pointers.
> > Things like typesafety, getting rid of macros in favour of inline
> > functions. The STL is another real reason to use C++ - the closest we have
> > to a standard for that sort of stuff. UML etc... There are a lot of very
> > practical reasons for using C++.
>
> Ahhh, I fear an outbreak of the unstoppable language zealot virus is
imminent!
Once it gets
airborne nothing can stop it!
Ahh, it's probably already to late... I can hear the sound of eager fingers
tapping on keyboards... save yourselves!!
I can't say I've ever actually come across a C++ "zealot".. most
seem to have an opinion similar to mine:
C++ sucks.
However, it sucks less than anything else I could use to do audio
development on linux right now.
7:04 a.m.
On Tue, Aug 31, 2004 at 04:52:33 +0100, Dave Griffiths wrote:
Truely.
I like the
OO-in-C style of programming, its pretty much the best of
both worlds IMHO. C syntax, but no C++ 'features'.
Not mention the lack of a maze of twisty ABI's... Just a quick side issue, I'm doing a lot of
message passing - in and out of
OSC, and then through my own realtime fifo IPC layer thingy into the audio
thread of my application. Are there any standard libraries or ways of doing
this all in one go? I guess the last step is very application dependant...
Not sure I understood the question, but the latest liblo supports OSC over
UNIX domain FIFOs. That doent sound like what you want though.
I guess something liblo could do to help if it doesnt allready is offer to
serialise an OSC message to a memory location, or return a pointer to one.
- Steve
7:05 a.m.
On Tue, Aug 31, 2004 at 01:15:24 -0400, Pete Bessman wrote:
At Tue, 31 Aug 2004 16:02:43 +0100,
Steve Harris wrote:
Obejctive C is OK, it uses messages (smalltalk style) rather than method
calls, and they have some performance limitations, but the class stuff is
all sane.
- Steve
I like the OO-in-C style of programming, its pretty much the best of both
worlds IMHO. C syntax, but no C++ 'features'.
Seriously. You can easily do Real OOP in C; the only thing it lacks
is syntactic sugar. I wish there was a real C++, as in a C that has
just had a few minor, incremental improvements made to it. C++ may
have a lot in common with C in a technical sense, but the mentality it
represents is almost completely orthogonal. (And yes, you can write C
style in C++, but then, why not just use C?)
7:08 a.m.
On Tue, Aug 31, 2004 at 01:43:31 -0600, martin rumori wrote:
AFAIK in the beginning it was never meant as a midi
replacement, but
should -in opposite to midi- not make any assumptions on the musical
meaning of the data being sent. especially in the field of new music
or sound art, MIDI is next to completely irrelevant as carrier for
musical data (but is still used for control data like sensor stuff
etc, since you can build such a thing with a small pic uC).
however, an "official" way of encapsulating midi in osc would maybe
push especially some commercial developers to osc, but i guess the
CNMAT folks don't want to have it in their official spec.
As Dave pointed out there is the 'm' type, but that doesnt fix any of
MIDIs problems, jsut a way of wrapping it in OSC.
I dont really think OSC needs to replace MIDI, if your doing 12 tone,
limited polyphony, bandwisth etc. stuff, which most people are, its fine.
- Steve
7:19 a.m.
On Tue, 31 Aug 2004 13:43:31 -0600, martin rumori wrote
On Tue, Aug 31, 2004 at 02:46:13PM -0400, Dave
Robillard wrote:
so if I'm writing a osc sequencer, is the best plan to leave the mapping open
for the user to modify?
I was wondering about this the other day - is
there no OSC 'standard'
for how to declare note-ons, offs, etc?
If OSC really is to become a MIDI replacement, there's needs to be an
explicitly defined standard that says "this is how a note is triggered"
AFAIK in the beginning it was never meant as a midi replacement, but
should -in opposite to midi- not make any assumptions on the musical
meaning of the data being sent. however, an "official" way of encapsulating
midi in osc would maybe
push especially some commercial developers to osc, but i guess the
CNMAT folks don't want to have it in their official spec.
simple midi messages are supported as a type in osc, but you'd have to write
your server to pick them up.
cheers,
dave
8:32 a.m.
On Tue, 31 Aug 2004 13:15:24 -0400
Pete Bessman <ninjadroid(a)gazuga.net> wrote:
The D programming language looks very promising in
this regard, but
its newsgroup faces a daily battle with people who seem more
interested in creating a religion than a tool.
I had a bit of a look at D and I was majorly underwhelmed. This
is a direct descendant of C, C++ and Java. It extends this lineage
a little, but completely ignores ideas from languages such as Perl,
Python, Ruby and the whole constellation of functional languges.
Now that I think about
it, that struggle seems to be a recurring theme in the world of
programming languages at large.
Has anyone else looked at O'Caml? :
http://www.ocaml.org/
I've been coding in it for about 6 weeks and I'm REALLY enjoying
it. Its the most fun I've had coding in ages.
If anyone has the FFTW sources on their machines, they already
have some O'Caml source :-). The FFTW authors wrote a program
in O'Caml to generate the C code for the codelets.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Linux everywhere pretty much eliminates the need for Java everywhere"
-- Bruce Ide in letter to LWN editors
8:47 a.m.
On Wed, Sep 01, 2004 at 10:03:18 +0100, Dave Griffiths wrote:
On Tue, 31 Aug 2004 13:43:31 -0600, martin rumori
wrote
I would say so yes, its possible that an OSC schema spe will be
standardised at soem point that would make it easier.
- Steve
On Tue, Aug 31, 2004 at 02:46:13PM -0400, Dave
Robillard wrote:
so if I'm writing a osc sequencer, is the best plan to leave the mapping open
for the user to modify? I was wondering about this the other day - is
there no OSC 'standard'
for how to declare note-ons, offs, etc?
If OSC really is to become a MIDI replacement, there's needs to be an
explicitly defined standard that says "this is how a note is triggered"
AFAIK in the beginning it was never meant as a midi replacement, but
should -in opposite to midi- not make any assumptions on the musical
meaning of the data being sent.
10:07 a.m.
On Wed, Sep 01, 2004 at 11:31:01AM +0100, Steve Harris wrote:
On Wed, Sep 01, 2004 at 10:03:18 +0100, Dave Griffiths
wrote:
not to mention the microtone-capabilities of your osc sequencer and
the sophisticated envelope control functions, which are hard to cover
with pure midi... :-))
martin
so if I'm writing a osc sequencer, is the
best plan to leave the
mapping open for the user to modify?
I would say so yes, its possible that an OSC schema spe will be
standardised at soem point that would make it easier.
10:25 a.m.
On Wed, Sep 01, 2004 at 09:49:36AM +0100, Steve Harris wrote:
Obejctive C is OK, it uses messages (smalltalk style)
rather than method
calls, and they have some performance limitations, but the class stuff is
all sane.
i like objc very much as well, didn't have the heart to mention it
here in this discussion... it's just one syntactical addition to c
plus some compiler directives.
steve, i never expected at all that i could look sane too you with the
weakly typed object system... :-)
martin
10:40 a.m.
At Wed, 1 Sep 2004 09:49:36 +0100,
Steve Harris wrote:
Obejctive C is OK, it uses messages (smalltalk style) rather than method
calls, and they have some performance limitations, but the class stuff is
all sane.
Good call, I forgot about it at the time of writing. It is quite
nice, and I like how the 'id' type obviates most of the need for
templates. The only complaint I have is that I think the class
declaration/definition syntax is... goofy... But that's certainly
tolerable.
--Pete
<http://www.gazuga.net>
"Nothing great was ever achieved by being realistic!" --Tom Venuto
11:02 a.m.
On Wed, Sep 01, 2004 at 08:24:20AM -0400, Pete Bessman wrote:
At Wed, 1 Sep 2004 09:49:36 +0100,
Steve Harris wrote:
sure. my only complaint is the lack of namespaces. and maybe missing
class variables, you have to use a static c thing for that.
not to mention the next foundation stuff. it's possible to write high
level portable code using gnustep on linux and cocoa on mac os x. i
just spent days of building an autoconf/automake build system that
runs both on gnustep and cocoa (avoiding gnustep-make but getting some
vars/paths out of it), had to steal some objc compiler/runtime
detection macros from different places...
but we are running straight OT now...
bests,
martin
Obejctive C is OK, it uses messages (smalltalk style) rather than method
calls, and they have some performance limitations, but the class stuff is
all sane.
Good call, I forgot about it at the time of writing. It is quite
nice, and I like how the 'id' type obviates most of the need for
templates. The only complaint I have is that I think the class
declaration/definition syntax is... goofy... But that's certainly
tolerable.
11:04 a.m.
At Wed, 1 Sep 2004 20:15:54 +1000,
Erik de Castro Lopo wrote:
On Tue, 31 Aug 2004 13:15:24 -0400
Pete Bessman <ninjadroid(a)gazuga.net> wrote:
That's actually precisely what I like about it. D is, depending on
your vantage point, a modernized C, a cleaned up C++, or a
non-retarded Java (sorry, I can't think of a more diplomatic way to
say that). That's all it's supposed to be. There isn't exactly
a dearth of more experimental languages out there, I like seeing
a real grizzled and pragmatic language like D pop up.
--Pete
<http://www.gazuga.net>
"Nothing great was ever achieved by being realistic!" --Tom Venuto
The D programming language looks very promising
in this regard, but
its newsgroup faces a daily battle with people who seem more
interested in creating a religion than a tool.
I had a bit of a look at D and I was majorly underwhelmed. This
is a direct descendant of C, C++ and Java. It extends this lineage
a little, but completely ignores ideas from languages such as Perl,
Python, Ruby and the whole constellation of functional languges.
1:49 p.m.
On Wed, 1 Sep 2004 05:48:15 -0600, martin rumori wrote
On Wed, Sep 01, 2004 at 11:31:01AM +0100, Steve Harris
wrote:
thats what I'm after :)
for anyone thats interested, I'm implementing a sequencer based on a text
score language I've developed for algorithmic melody generation and live
programming: http://www.pawfal.org/index.php?page=ScoreCode
it sounds a bit strange maybe, but I managed to perform a prototype version of
this live a couple of months ago, and it seems to work well.
dave
On Wed, Sep 01, 2004 at 10:03:18 +0100, Dave
Griffiths wrote:
not to mention the microtone-capabilities of your osc sequencer and
the sophisticated envelope control functions, which are hard to cover
with pure midi... :-)) so if I'm writing a osc sequencer, is the
best plan to leave the
mapping open for the user to modify?
I would say so yes, its possible that an OSC schema spe will be
standardised at soem point that would make it easier.
5:35 p.m.
On Wed, 2004-09-01 at 04:52, Steve Harris wrote:
I dont really think OSC needs to replace MIDI, if your
doing 12 tone,
limited polyphony, bandwisth etc. stuff, which most people are, its fine.
- Steve
Sure, but the control issue is a nuisance, even for 'most people' -
assigning numbers to things just sucks - this is 2004, not 1974 :)
It'd be nice if (when) OSC has service discovery for a synth to just
dump all it's parameters (valid commands), so something like a sequencer
could have a drop down list of what control you want to use - all with
nice names that actually make sense. "Controller 79" doesn't help much.
Then we're at a stage where any device (computer, synth, whatever) can
just plug into the switch on your network, and all of a sudden your DAW
knows exactly what just showed up on the network, what it can do, and
how to control it. That's a few orders of magnitude cooler than
Controller 79 :)
It's also much easier, users don't have to figure out what Alsa seq
ports to connect, or just guess by looking at the patch bay what the
app's audio ports are, it can all be just magic. As an example; In MuSE
you could just select a running soft synth (not a plugin!) from a
dropdown on a track and have everything automatically work, the
sequencer can figure out the I/O and control stuff itself and hook it
all up.
Speaking of service discovery Steve, I saw in the liblo TODO that you
were looking at implementing it (with howl), but with low priority. Is
that a couple months low priority or 2009 low priority? Peronally I
think it'd be a huge step forward..
-DR-
5:41 p.m.
On Wed, 2004-09-01 at 07:48, martin rumori wrote:
On Wed, Sep 01, 2004 at 11:31:01AM +0100, Steve Harris
wrote:
Imagine a sequencer where, instead of little straight bars representing
notes, the 'piano roll' just allowed you to draw a line to represent
frequency.. with any angle, straight or curved (bezier), etc. Wow..
Control could be like that too, with overlay and everything, but having
that for pitch would be amazing.. has something like this ever been done
before?
-DR-
On Wed, Sep 01, 2004 at 10:03:18 +0100, Dave
Griffiths wrote:
not to mention the microtone-capabilities of your osc sequencer and
the sophisticated envelope control functions, which are hard to cover
with pure midi... :-)) so if I'm writing a osc sequencer, is the
best plan to leave the
mapping open for the user to modify?
I would say so yes, its possible that an OSC schema spe will be
standardised at soem point that would make it easier. 
5:42 p.m.
Erik de Castro Lopo wrote:
Has anyone else looked at O'Caml? :
http://www.ocaml.org/
I've been coding in it for about 6 weeks and I'm REALLY enjoying
it. Its the most fun I've had coding in ages.
Yes, those modern functional languages really bring back the joy to
hacking. :) The trouble with ML and Haskell is, though, while they
already have some facilities for graphics programming, at this time they
mostly lack other multimedia libraries. (And I'm wondering how suitable
Haskell would be for realtime stuff, given its lazy evaluation strategy.
ML certainly is, in fact it's been reported that in some cases compiled
ML is even faster than C ...)
But the world doesn't end there. E.g., there's Faust for audio
programming (developed at Grame, must admit that I haven't tried it yet,
but I certainly will), and (shameless plug) Q (http://q-lang.sf.net),
which already has interfaces to PortAudio, libsndfile (of course ;-),
MIDI, OSC, SuperCollider and whatnot. Q takes the route to represent
MIDI and OSC messages as high-level (algebraic) data types, so most
transformations (such as mapping MIDI input to SuperCollider control
messages) are almost trivial to implement. Q is also embeddable in C, so
you can use it inside a C/C++ program if you need that.
If anyone has the FFTW sources on their machines, they
already
have some O'Caml source :-). The FFTW authors wrote a program
in O'Caml to generate the C code for the codelets.
Yes, that's a nice twist. :) Apparently plugging together the different
FFTW algorithms becomes so complicated that they use OCaml to do
algebraic simplifications on the resulting graphs.
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
6:53 p.m.
New subject: [linux-audio-dev] Re: OSC vs MIDI
Dave Griffiths wrote:
On Tue, 31 Aug 2004 16:02:43 +0100, Steve Harris
wrote
i used libOMC [which is the old library "upgraded" to be buildable
again] in RunMotherfuckerRun player (http://www.artm.org/). it's
available here: http://www.piksel.no/pwiki/OpenSoundControl
it wasn't maintained since around piksel gathering (nov 2003)... oh, and
i'm afraid i have fixed some bugs on artist's offline machine and never
brought the sources back to piksel site. the fixes made it compatible
with Max/MSP's OSC objects (half of the installation is a max patch
running on a mac). if Steve's interested i could find it.
i believe veejay uses it's own OSC implementation (probably based on the
same old implementation but i'm not sure). you could use it to test liblo.
we are considering to start using liblo as "piksel-approved" osc
implementation instead of libOMC.
and afaik there are OSC objects for PureData. i was testing earlier
versions of RmR with PureData coz i don't have a Mac myself. So it was
compatible with those as well.
finally, some of our (http://lab.v2.nl/) artistic hardware speaks OSC
over bluetooth, but it's irrelevant coz there's always only one last
prototype ;-)
On Tue, Aug 31, 2004 at 02:48:46PM +0100, Dave
Griffiths wrote:
Ah, OK. Well thats one more test, I tested liblo against the
original C implementaion when I started it, and after that against
itsself, but I get nervous about self tested software. I was never
sure the old C library was doing what its supposed to though,
couldn't get it to build on a modern machine, and the only binaries
I had were 4 or 5 years old :)
Well, everyone seems to be using liblo :) BTW, if
you have reasonable OSC covereage I'd be very interested in
compatibility tests between whatever you're using and liblo.
Very early days, I've only implemented simple messages so far - but I'm using
liblo for my server and some python I've nicked for the client
http://cvs.sourceforge.net/viewcvs.py/pure-data/supercollider/python/OSC.py
Seems flawless so far though, and liblo's got a nice clean api. 
2 Sep
2 Sep
6:41 a.m.
Dr.Graef(a)t-online.de (Albert Graef) writes:
Erik de Castro Lopo wrote:
There is the Haskore Haskell package. The problem I had with doing
haskell audio work that binary I/O was too slow.
Immanuel
Has anyone else looked at O'Caml? :
http://www.ocaml.org/
I've been coding in it for about 6 weeks and I'm REALLY enjoying
it. Its the most fun I've had coding in ages.
Yes, those modern functional languages really bring back the joy to
hacking. :) The trouble with ML and Haskell is, though, while they
already have some facilities for graphics programming, at this time
they mostly lack other multimedia libraries. (And I'm wondering how
suitable Haskell would be for realtime stuff, given its lazy
evaluation strategy. ML certainly is, in fact it's been reported that
in some cases compiled ML is even faster than C ...)
6:54 a.m.
On Wed, Sep 01, 2004 at 03:21:17PM -0400, Dave Robillard wrote:
On Wed, 2004-09-01 at 04:52, Steve Harris wrote:
Funny you should say that... I'm hoping to find time to add the propsed
rec. for OSC service exploration/enumeration to liblo (not discovery,
thats a seperate problem) that would allow (limited) generic OSC clients
that coul list hte parameters of an OSC service, and witha bit of extra
code in the OSC servers will allow you draw sliders and so on.
I dont really think OSC needs to replace MIDI, if
your doing 12 tone,
limited polyphony, bandwisth etc. stuff, which most people are, its fine.
- Steve
Sure, but the control issue is a nuisance, even for 'most people' -
assigning numbers to things just sucks - this is 2004, not 1974 :)
It'd be nice if (when) OSC has service discovery for a synth to just
dump all it's parameters (valid commands), so something like a sequencer
could have a drop down list of what control you want to use - all with
nice names that actually make sense. "Controller 79" doesn't help much.
Speaking of service discovery Steve, I saw in the
liblo TODO that you
were looking at implementing it (with howl), but with low priority. Is
that a couple months low priority or 2009 low priority? Peronally I
think it'd be a huge step forward..
Its a when enough people have MDNS servers on thier machines priority,
thats likly to be sometime after Gnome 2.6 is out, as it has a MDNS
server built in.
Ofcourse if somewone wants to work on zeroconf support before then, I wont
stop them :) I agree it would be a Good ThingTM.
- Steve
7:13 a.m.
New subject: [linux-audio-dev] Re: OSC vs MIDI
On Wed, Sep 01, 2004 at 10:24:11PM +0200, Artem Baguinski wrote:
it wasn't maintained since around piksel gathering
(nov 2003)... oh, and
i'm afraid i have fixed some bugs on artist's offline machine and never
brought the sources back to piksel site. the fixes made it compatible
with Max/MSP's OSC objects (half of the installation is a max patch
running on a mac). if Steve's interested i could find it.
Dont worry about it for the moment, but I may get back to you when I add
bundle support. I think SC uses bundles a lot so you may be stuck there.
and afaik there are OSC objects for PureData. i was
testing earlier
versions of RmR with PureData coz i don't have a Mac myself. So it was
compatible with those as well.
Those are also based on the libOSC source.
finally, some of our (http://lab.v2.nl/) artistic
hardware speaks OSC
over bluetooth, but it's irrelevant coz there's always only one last
prototype ;-)
OSC over bluetooth is interesting. Any comments on it? How easy is the
hardware to build? I know you can wire PICs to USB easily, but I dont know
much about bluetooth.
Would it be worth adding a bluetooth transport to liblo?
- Steve
1:22 p.m.
New subject: [linux-audio-dev] Re: OSC vs MIDI
OSC over bluetooth is interesting. Any comments on it?
How easy is the
hardware to build? I know you can wire PICs to USB easily, but I dont know
much about bluetooth.
Would it be worth adding a bluetooth transport to liblo?
i never was able to get below a latency nelow 15-20 ms and spikes here
and there (if you want run jitter-free i guess you have a latency of
30-50ms or more). i don't know if this is only my setup or if this is
normal with bluetooth. for real-time musical controlers it's way to
slow. but i guess there are still enough applications were latency
doesn't matter.
what do you mean with a bluetooth transport?
2:08 p.m.
On Thu, 2004-09-02 at 04:38, Steve Harris wrote:
On Wed, Sep 01, 2004 at 03:21:17PM -0400, Dave
Robillard wrote:
What do you mean by "limited", and why would drawing sliders require
extra code in the OSC servers?
Maybe I misunderstand you (likely), but it sounds like maybe a little
too much specific stuff in liblo to me, which I know you're against.
Doesn't service discovery and a standard for how to query parameters
solve this problem? (ie client discovers a new server, sends
"/send_params MY_ADDR", and gets all the information in a
standard-defined way).
Basically, I don't see what needs to be done to liblo, other than the
service discovery part.
-DR-
On Wed, 2004-09-01 at 04:52, Steve Harris wrote:
Funny you should say that... I'm hoping to find time to add the propsed
rec. for OSC service exploration/enumeration to liblo (not discovery,
thats a seperate problem) that would allow (limited) generic OSC clients
that coul list hte parameters of an OSC service, and witha bit of extra
code in the OSC servers will allow you draw sliders and so on. I dont really think OSC needs to replace MIDI, if
your doing 12 tone,
limited polyphony, bandwisth etc. stuff, which most people are, its fine.
- Steve
Sure, but the control issue is a nuisance, even for 'most people' -
assigning numbers to things just sucks - this is 2004, not 1974 :)
It'd be nice if (when) OSC has service discovery for a synth to just
dump all it's parameters (valid commands), so something like a sequencer
could have a drop down list of what control you want to use - all with
nice names that actually make sense. "Controller 79" doesn't help much.
5:11 p.m.
Hallo,
Dave Robillard hat gesagt: // Dave Robillard wrote:
Imagine a sequencer where, instead of little straight
bars representing
notes, the 'piano roll' just allowed you to draw a line to represent
frequency.. with any angle, straight or curved (bezier), etc. Wow..
Control could be like that too, with overlay and everything, but having
that for pitch would be amazing.. has something like this ever been done
before?
If you have Pd installed:
/usr/lib/pd/doc/7.stuff/data-structures/7.sequencer.pd
I'm currently preparing a workshop anout this stuff to be held at the
pd~convention 04 in Graz at the end of month, after that I'll publish
it as a tutorial on what Pd data structures/templates which hopefully
is a bit more accessible than the included documentation.
Ciao
--
Frank Barknecht _ ______footils.org__
3 Sep
3 Sep
5:08 a.m.
On ons, 2004-09-01 at 21:26, Dave Robillard wrote:
On Wed, 2004-09-01 at 07:48, martin rumori wrote:
Isn't this very similar to drawing the midi-pitchbend? EditTrack did
that in the 80's. You could also draw values for volume and controllers
if you wanted sophisticated envelopes.
IIRC mouse-dragging in the piano-roll would "spray paint" notes all over
the place ... Combine that with a synth patch with very closely spaced
notes and we are getting pretty close to what you are talking about.
Perhaps with a bit of portamento to smooth out the rough edges
/jens
On Wed, Sep 01, 2004 at 11:31:01AM +0100, Steve
Harris wrote:
Imagine a sequencer where, instead of little straight bars representing
notes, the 'piano roll' just allowed you to draw a line to represent
frequency.. with any angle, straight or curved (bezier), etc. Wow..
Control could be like that too, with overlay and everything, but having
that for pitch would be amazing.. has something like this ever been done
before?
On Wed, Sep 01, 2004 at 10:03:18 +0100, Dave
Griffiths wrote:
not to mention the microtone-capabilities of your osc sequencer and
the sophisticated envelope control functions, which are hard to cover
with pure midi... :-)) so if I'm writing a osc sequencer, is the
best plan to leave the
mapping open for the user to modify?
I would say so yes, its possible that an OSC schema spe will be
standardised at soem point that would make it easier. -DR-
6:51 a.m.
New subject: [linux-audio-dev] Re: OSC vs MIDI
On Thursday 02 September 2004 17.06, smoerk wrote:
I've noticed a lot of complaining about bluetooth wireless mice not
being seriously usable for FPS games and the like.
Logitech has a wireless optical mouse that comes in two models; the
"FastRF" MX700, and the bluetooth MX900. People who have used both
say that the MX700 performs a lot better than the MX900, and people
have returned MX900s after discovering that the performance is
unacceptable for gaming. The mice identical, except for the wireless
protocol, though marketting (obviously) suggests that the (much more
expensive) bluetooth solution is plain better, with no side effects.
Some customer asked Logitech about this, and Logitech replied that
bluetooth has much lower bandwidth than their FastRF system...
I *think* bluetooth should be able to handle the bandwith requirements
of a mouse (125 Hz frame rate for the MX models, IIRC), but 15-20 ms
latency spikes would be an issue that cannot be fully compensated for
regardless of bandwidth. Jitter or delay (buffering to eliminate
jitter) would cause problems with real time controllers, such as mice
or musical controllers.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
OSC over
bluetooth is interesting. Any comments on it? How easy
is the hardware to build? I know you can wire PICs to USB easily,
but I dont know much about bluetooth.
Would it be worth adding a bluetooth transport to liblo?
i never was able to get below a latency nelow 15-20 ms and spikes
here and there (if you want run jitter-free i guess you have a
latency of 30-50ms or more). i don't know if this is only my setup
or if this is normal with bluetooth. for real-time musical
controlers it's way to slow. but i guess there are still enough
applications were latency doesn't matter. 
8:54 a.m.
Jens M Andreasen <jens.andreasen(a)chello.se> wrote:
IIRC mouse-dragging in the piano-roll would
"spray paint" notes all over
the place ... Combine that with a synth patch with very closely spaced
notes and we are getting pretty close to what you are talking about.
Perhaps with a bit of portamento to smooth out the rough edges
Masking?
8:24 p.m.
On Thu, Sep 02, 2004 at 11:53:37 -0400, Dave Robillard wrote:
The liblo API doesnt not currently have any way to specify what the ranges
on the parameters are, so the library cant report it, so you cant make
(useful) sliders.
Funny you
should say that... I'm hoping to find time to add the propsed
rec. for OSC service exploration/enumeration to liblo (not discovery,
thats a seperate problem) that would allow (limited) generic OSC clients
that coul list hte parameters of an OSC service, and witha bit of extra
code in the OSC servers will allow you draw sliders and so on.
What do you mean by "limited", and why would drawing sliders require
extra code in the OSC servers? Maybe I misunderstand you (likely), but it sounds like
maybe a little
too much specific stuff in liblo to me, which I know you're against.
Doesn't service discovery and a standard for how to query parameters
solve this problem? (ie client discovers a new server, sends
"/send_params MY_ADDR", and gets all the information in a
standard-defined way).
Service discovery just covers being able to locate liblo servers, you need
some other stuff to actually find out what the controls are. The other
stuff is heading towards standardisation, but hte service discovery isn't
- the zeroconf inplementation would be fairly obvious though.
Basically, I don't see what needs to be done to
liblo, other than the
service discovery part.
Nothing, but the API doesnt include enough stuff yet. I dont really want
to expand the API until its standardised properly though.
- Steve
8:32 p.m.
New subject: [linux-audio-dev] Re: OSC vs MIDI
On Fri, Sep 03, 2004 at 10:32:40 +0200, David Olofson wrote:
The main advnatage of bluetooth mice to me would be that I wouldn't need a
USB dongle sticking out of my laptop, I could use the builtin bluetooth
stuff. Not that I use mice very often :)
i never was
able to get below a latency nelow 15-20 ms and spikes
here and there (if you want run jitter-free i guess you have a
latency of 30-50ms or more). i don't know if this is only my setup
or if this is normal with bluetooth. for real-time musical
controlers it's way to slow. but i guess there are still enough
applications were latency doesn't matter.
I've noticed a lot of complaining about bluetooth wireless mice not
being seriously usable for FPS games and the like. I *think* bluetooth should be able to handle the
bandwith requirements
of a mouse (125 Hz frame rate for the MX models, IIRC), but 15-20 ms
latency spikes would be an issue that cannot be fully compensated for
regardless of bandwidth. Jitter or delay (buffering to eliminate
jitter) would cause problems with real time controllers, such as mice
or musical controllers.
Bluetooth can do realtime ADPCM audio, so a mouse should be no problem.
Maybe HID controllers use a different bit of the protocol?
- Steve
9:58 p.m.
On Fri, 2004-09-03 at 02:52, Jens M Andreasen wrote:
On ons, 2004-09-01 at 21:26, Dave Robillard wrote:
Way, way, way too tedious to be practical. It's of course possible to
do pitchbends, but it's not the same.
On Wed, 2004-09-01 at 07:48, martin rumori
wrote:
Isn't this very similar to drawing the midi-pitchbend? EditTrack did
that in the 80's. You could also draw values for volume and controllers
if you wanted sophisticated envelopes. On Wed, Sep 01, 2004 at 11:31:01AM +0100, Steve
Harris wrote:
Imagine a sequencer where, instead of little straight bars representing
notes, the 'piano roll' just allowed you to draw a line to represent
frequency.. with any angle, straight or curved (bezier), etc. Wow..
Control could be like that too, with overlay and everything, but having
that for pitch would be amazing.. has something like this ever been done
before?
On Wed, Sep 01, 2004 at 10:03:18 +0100, Dave
Griffiths wrote:
> so if I'm writing a osc sequencer, is the best plan to leave the
> mapping open for the user to modify?
I would say so yes, its possible that an OSC schema spe will be
standardised at soem point that would make it easier.
not to mention the microtone-capabilities of your osc sequencer and
the sophisticated envelope control functions, which are hard to cover
with pure midi... :-)) IIRC mouse-dragging in the piano-roll would
"spray paint" notes all over
the place ... Combine that with a synth patch with very closely spaced
notes and we are getting pretty close to what you are talking about.
Perhaps with a bit of portamento to smooth out the rough edges
Not really at all... like you said, it would be a whole whack of "spray
painted" notes, not one continuous note. The point was it would be nice
to be able to break out of the limitations of MIDIs notes.
You could write a MIDI sequencer that abstracts this and uses noteons
and pitchbend to do it of course, but it doesn't exist right now (in the
free world anyway) AFAIK
-DR-
10:03 p.m.
New subject: [linux-audio-dev] Re: OSC vs MIDI
On Saturday 04 September 2004 00.16, Steve Harris wrote:
[...]
I dunno... Either way, ADPCM audio is just a matter of bandwidth, but
latency seems to be the issue here. 15-20 ms (in addition to
driver/OS polling latency + jitter and video buffering latency) is
unacceptable for a gaming mouse, so I suspect that messages are just
sent and handled ASAP, without timestamping. Just means you get
terrible jitter instead, which is probably *worse* than the
latency...
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
I *think*
bluetooth should be able to handle the bandwith
requirements of a mouse (125 Hz frame rate for the MX models,
IIRC), but 15-20 ms latency spikes would be an issue that cannot
be fully compensated for regardless of bandwidth. Jitter or delay
(buffering to eliminate jitter) would cause problems with real
time controllers, such as mice or musical controllers.
Bluetooth can do realtime ADPCM audio, so a mouse should be no
problem. Maybe HID controllers use a different bit of the protocol?
10:05 p.m.
On Fri, 2004-09-03 at 18:07, Steve Harris wrote:
On Thu, Sep 02, 2004 at 11:53:37 -0400, Dave Robillard
wrote:
The liblo API doesnt not currently have any way to specify what the ranges
on the parameters are, so the library cant report it, so you cant make
(useful) sliders.
My point was that ranges for controls and stuff like that probably don't
really belong in the liblo API at all.. I would expect you, wanting to
keep liblo simple, would agree on that.
Wouldn't just a standard that defines how OSC apps can tell each other
about their controls (and ranges, and all that) be much nicer? Things
like this depending on liblo is probably a bad idea IMO.
Something like:
/foo/define_control "volume" MIN MAX
or whatever.. then the service discovery is all liblo needs to bother
with, and apps can talk to each other following this hypothetical RFC.
Then again, maybe if it WAS in liblo, there wouldn't be problems with
changing the RFC, and breaking old clients, and all that nasty stuff.
Hmm.
Thoughts?
-DR-
Funny you
should say that... I'm hoping to find time to add the propsed
rec. for OSC service exploration/enumeration to liblo (not discovery,
thats a seperate problem) that would allow (limited) generic OSC clients
that coul list hte parameters of an OSC service, and witha bit of extra
code in the OSC servers will allow you draw sliders and so on.
What do you mean by "limited", and why would drawing sliders require
extra code in the OSC servers? Maybe I misunderstand you (likely), but it sounds
like maybe a little
too much specific stuff in liblo to me, which I know you're against.
Doesn't service discovery and a standard for how to query parameters
solve this problem? (ie client discovers a new server, sends
"/send_params MY_ADDR", and gets all the information in a
standard-defined way).
Service discovery just covers being able to locate liblo servers, you need
some other stuff to actually find out what the controls are. The other
stuff is heading towards standardisation, but hte service discovery isn't
- the zeroconf inplementation would be fairly obvious though.
Basically, I don't see what needs to be done
to liblo, other than the
service discovery part.
Nothing, but the API doesnt include enough stuff yet. I dont really want
to expand the API until its standardised properly though.
4 Sep
4 Sep
5:55 a.m.
On lör, 2004-09-04 at 01:41, Dave Robillard wrote:
In monomode, with sustain pedal down, it would be continous ..
On Fri, 2004-09-03 at 02:52, Jens M Andreasen wrote:
Is not the same as what?
On ons, 2004-09-01 at 21:26, Dave Robillard
wrote:
Way, way, way too tedious to be practical. It's of course possible to
do pitchbends, but it's not the same. On Wed, 2004-09-01 at 07:48, martin rumori
wrote:
Isn't this very similar to drawing the midi-pitchbend? EditTrack did
that in the 80's. You could also draw values for volume and controllers
if you wanted sophisticated envelopes. On Wed, Sep 01, 2004 at 11:31:01AM +0100, Steve
Harris wrote:
> On Wed, Sep 01, 2004 at 10:03:18 +0100, Dave Griffiths wrote:
> > so if I'm writing a osc sequencer, is the best plan to leave the
> > mapping open for the user to modify?
>
> I would say so yes, its possible that an OSC schema spe will be
> standardised at soem point that would make it easier.
not to mention the microtone-capabilities of your osc sequencer and
the sophisticated envelope control functions, which are hard to cover
with pure midi... :-))
Imagine a sequencer where, instead of little straight bars representing
notes, the 'piano roll' just allowed you to draw a line to represent
frequency.. with any angle, straight or curved (bezier), etc. Wow..
Control could be like that too, with overlay and everything, but having
that for pitch would be amazing.. has something like this ever been done
before?
IIRC mouse-dragging in the piano-roll would
"spray paint" notes all over
the place ... Combine that with a synth patch with very closely spaced
notes and we are getting pretty close to what you are talking about.
Perhaps with a bit of portamento to smooth out the rough edges
Not really at all... like you said, it would be a whole whack of "spray
painted" notes, not one continuous note. ... The point was it
would be nice
to be able to break out of the limitations of MIDIs notes.
OK. Then we are back to modifying pitcbend and controllers which *will*
give you unlimited continous control of a note. If we stick to the
intended use of midi, that is still a 16 voice part. My point being that
it can be done in OSC or MIDI, the protocol is not an issue. The problem
lies in presenting and manipulating the data which will be tedious
either way.
You could write a MIDI sequencer that abstracts this and uses noteons
and pitchbend to do it of course, but it doesn't exist right now (in the
free world anyway) AFAIK
You wouldn't need any noteons (ok, perhaps one to get started) if volume
was a continous controller. If you want to break out of the limitations,
you can do that today. These are not the noteons you are looking for ...
/jens
-DR-
9:10 a.m.
New subject: [linux-audio-dev] Re: OSC vs MIDI
On Sat, Sep 04, 2004 at 01:44:28 +0200, David Olofson wrote:
On Saturday 04 September 2004 00.16, Steve Harris
wrote:
[...]
I dunno... Either way, ADPCM audio is just a matter of bandwidth, but
latency seems to be the issue here. 15-20 ms (in addition to
driver/OS polling latency + jitter and video buffering latency) is
unacceptable for a gaming mouse, so I suspect that messages are just
sent and handled ASAP, without timestamping. Just means you get
terrible jitter instead, which is probably *worse* than the
latency...
There cant be any latency jitter on the audio... I would guess that either
that part of the protocol is reserved for audio in some way, or the
logitech implementation is just rubbish.
- Steve
I *think*
bluetooth should be able to handle the bandwith
requirements of a mouse (125 Hz frame rate for the MX models,
IIRC), but 15-20 ms latency spikes would be an issue that cannot
be fully compensated for regardless of bandwidth. Jitter or delay
(buffering to eliminate jitter) would cause problems with real
time controllers, such as mice or musical controllers.
Bluetooth can do realtime ADPCM audio, so a mouse should be no
problem. Maybe HID controllers use a different bit of the protocol?
1:15 p.m.
New subject: [linux-audio-dev] Re: OSC vs MIDI
Steve Harris wrote:
i'm not involved in any of the projects where we used it. I know that
for one project it was implemented in java on something like java stamp.
Next year my research line is gonna merge with the sensors / wearables /
wireless research of our hardware engineer and i'll be more informed.
On Wed, Sep 01, 2004 at 10:24:11PM +0200, Artem
Baguinski wrote:
right...
it wasn't maintained since around piksel
gathering (nov 2003)... oh, and
i'm afraid i have fixed some bugs on artist's offline machine and never
brought the sources back to piksel site. the fixes made it compatible
with Max/MSP's OSC objects (half of the installation is a max patch
running on a mac). if Steve's interested i could find it.
Dont worry about it for the moment, but I may get back to you when I add
bundle support. I think SC uses bundles a lot so you may be stuck there. finally, some
of our (http://lab.v2.nl/) artistic hardware speaks OSC
over bluetooth, but it's irrelevant coz there's always only one last
prototype ;-)
OSC over bluetooth is interesting. Any comments on it? How easy is the
hardware to build? I know you can wire PICs to USB easily, but I dont know
much about bluetooth. Would it be worth adding a bluetooth transport to
liblo?
doesn't liblo support something like "custom pluggable transport"?
that'd be useful for seldom used transports i guess.
2:19 p.m.
New subject: [linux-audio-dev] Re: OSC vs MIDI
On Sat, Sep 04, 2004 at 04:46:17PM +0200, Artem Baguinski wrote:
No it doesn't, I think thats taking modularity too far. Its not much code
to add a new transport though.
- Steve
Would it be
worth adding a bluetooth transport to liblo?
doesn't liblo support something like "custom pluggable transport"?
that'd be useful for seldom used transports i guess.
2:29 p.m.
On Fri, Sep 03, 2004 at 07:48:22PM -0400, Dave Robillard wrote:
My point was that ranges for controls and stuff like that probably don't
really belong in the liblo API at all.. I would expect you, wanting to
keep liblo simple, would agree on that.
My intention is to keep the liblo *API* simple, the library itsself is
allready fairly complicated, the idea is that it hides the complexities of
the nuts-and-bolts of the protocol.
Basically, I don't see what needs to be done to
liblo, other than the
service discovery part.
Nothing, but the API doesnt include enough stuff yet. I dont really want
to expand the API until its standardised properly though. Wouldn't just a standard that defines how OSC apps
can tell each other
about their controls (and ranges, and all that) be much nicer? Things
like this depending on liblo is probably a bad idea IMO.
I think we're agreeing, but using different terminology.
The proposed rec. covers method querying, but it needs some API support to
make it simple enough for enough people to bother using it for it to take
off.
FWIW the propsed method query system is documented here:
http://www.opensoundcontrol.org/papers/query_system/osc-query-system.pdf
- Steve
7:50 p.m.
Jens M Andreasen wrote:
On ons, 2004-09-01 at 21:26, Dave Robillard wrote:
>On Wed, 2004-09-01 at 07:48, martin rumori wrote:
>>On Wed, Sep 01, 2004 at 11:31:01AM +0100, Steve Harris wrote:
>>>On Wed, Sep 01, 2004 at 10:03:18 +0100, Dave Griffiths wrote:
>Imagine a sequencer where, instead of little straight bars representing
>notes, the 'piano roll' just allowed you to draw a line to represent
>frequency.. with any angle, straight or curved (bezier), etc. Wow..
>Control could be like that too, with overlay and everything, but having
>that for pitch would be amazing.. has something like this ever been done
>before?
Sorry to jump in in the middle of thread without reading it from the
top. But, I just had to say this brought up images of that compositon
tool Xenakis created ... I can't remember what it was called. Anyone
here know?
-Eric Rz.
6 Sep
6 Sep
11:39 a.m.
New subject: [linux-audio-dev] Re: OSC vs MIDI
Dave Griffiths wrote:
a long-term heads-up: when Ardour gets MIDI sequencing capabilities,
it will includes OSC sequencing, and potentially other "sparse"
byte-oriented data formats too.
--p
On Tue, 31 Aug 2004 13:43:31 -0600, martin rumori
wrote
so if I'm writing a osc sequencer
are you?
i'd like to see ;-)
2:06 p.m.
Hallo,
Eric Dantan Rzewnicki hat gesagt: // Eric Dantan Rzewnicki wrote:
Sorry to jump in in the middle of thread without
reading it from the
top. But, I just had to say this brought up images of that compositon
tool Xenakis created ... I can't remember what it was called. Anyone
here know?
You mean the UPIC? (Now CCMIX)
Some random links:
http://www.ccmix.com/
http://www.xenakisworld.com/article_001.php
http://www.mode.com/catalog/098_9ccmix.html
http://www.emfmedia.org/artists/xenakis.html
(My usual Pd plug: UPIC and it's use in for example "Mykenae alpha"
was one of the inspirations for Pd's data structures. ;)
Ciao
--
Frank Barknecht _ ______footils.org__
7 Sep
7 Sep
1:43 a.m.
Frank Barknecht wrote:
Hallo,
Eric Dantan Rzewnicki hat gesagt: // Eric Dantan Rzewnicki wrote:
Yes, thank you Frank, that's it.
getting off topic a bit, and on a personal note, the fact that I first
learned of Xenaxis in an English class in my last year of undergraduate
study indicates just how poorly suited I and my music school were for
each other. :-(
-Eric Rz.
Sorry to jump in in the middle of thread without
reading it from the
top. But, I just had to say this brought up images of that compositon
tool Xenakis created ... I can't remember what it was called. Anyone
here know?
You mean the UPIC? (Now CCMIX)
Some random links:
http://www.ccmix.com/
http://www.xenakisworld.com/article_001.php
http://www.mode.com/catalog/098_9ccmix.html
http://www.emfmedia.org/artists/xenakis.html
(My usual Pd plug: UPIC and it's use in for example "Mykenae alpha"
was one of the inspirations for Pd's data structures. ;)
7176
days inactive
7182
days old
linux-audio-dev@lists.linuxaudio.org
52 comments
17 participants
participants (17)
-
Artem Baguinski -
Dave Griffiths -
Dave Robillard -
David Olofson -
Dr.Graef＠t-online.de -
Eric Dantan Rzewnicki -
Erik de Castro Lopo -
Frank Barknecht -
Immanuel Litzroth -
Jens M Andreasen -
martin rumori -
Paul Davis -
Pete Bessman -
Robert Jonsson -
RTaylor -
smoerk -
Steve Harris