15 Mar
2005
15 Mar
'05
4:24 p.m.
Hi all,
after some of the latest discussions about audio-apps without gui, my head is
filled with giving JackMix[1] OSC-Support and perhaps splitting it into a
text-based / osc-based server doing the mixing and a gui...
So my question arises: Which OSC-implementation to use?
I had a look into Steve Harris' liblo and libOSC++. The later seems more
appealing to me since I am a C++-Guy.
What do you folks think? What do you propose? What are you using?
Arnold
[1] http://roederberg.dyndns.org/~arnold/jackmix/
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
15 Mar
15 Mar
4:59 p.m.
On Tue, 2005-03-15 at 20:12, Arnold Krille wrote:
Hi all,
after some of the latest discussions about audio-apps without gui, my head is
filled with giving JackMix[1] OSC-Support and perhaps splitting it into a
text-based / osc-based server doing the mixing and a gui...
So my question arises: Which OSC-implementation to use?
I had a look into Steve Harris' liblo and libOSC++. The later seems more
appealing to me since I am a C++-Guy.
What do you folks think? What do you propose? What are you using?
I'm a C++ guy, and I haven't looked in much depth at the alternatives,
but I find liblo extremely simple and elegant to use.
I use a ringbuffer layer on top of liblo to get the messages sent
automatically to an rt audio thread, but I think this feature is
planned/or possibly exists for liblo already?
cheers,
dave
6:02 p.m.
New subject: [linux-audio-dev] OSC-Question - Addition
One more question: If I interpret the headers (of liblo) right, OSC is only
for passing messages, not for getting feedback? At least not getting feedback
without the "server" sending an own message back?
So if I want to split my mixer in a non-gui server and a gui and want the gui
to represent the actual server-state, the server has to send messages to the
gui-client?
Which has the positive side effect of the gui beeing updated if the
server-state is changed from another client. (Just imagine two clients on
different PC's controlling one mixer on a third PC. ;-) )
Arnold
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
7:42 p.m.
New subject: [linux-audio-dev] OSC-Question - Addition
On Tue, Mar 15, 2005 at 11:01:58PM +0100, Arnold Krille wrote:
One more question: If I interpret the headers (of liblo) right, OSC is only
for passing messages, not for getting feedback? At least not getting feedback
without the "server" sending an own message back?
So if I want to split my mixer in a non-gui server and a gui and want the gui
to represent the actual server-state, the server has to send messages to the
gui-client?
Yes, thats right. OSC is fully asynchronus.
Which has the positive side effect of the gui beeing
updated if the
server-state is changed from another client. (Just imagine two clients on
different PC's controlling one mixer on a third PC. ;-) )
Right, this is a good thing, and most OSC linux apps seem to be allowing
it.
- Steve
6:22 p.m.
hi arnold,
On Tue, Mar 15, 2005 at 09:12:19PM +0100, Arnold Krille wrote:
I had a look into Steve Harris' liblo and
libOSC++. The later seems more
appealing to me since I am a C++-Guy.
two years ago, i added the network classes (Inet*) to libOSC++, fixed
some bugs, cleaned up a bit... the library was used in different
projects (http://listen.gmd.de, http://www.grenzenlosefreiheit.de,
plus the wiretap thing of the original libOSC++ developers) and
appeared to be stable.
BUT: as far as i know, there is not much development ongoing at the
moment, and i ever planned some redesign for the whole library (i
don't consider using a std::string as container for an osc message as
a nice example for object oriented design...), but unfortunetaly there
wasn't enough time...
just some background information concerning libOSC++. be sure to pick
the "fraunhofer" branch if using it. there is a download page at
http://libosc.rumori.de
but i guess that liblo might be the better choice, it's in vivid
development and used by much more projects than libOSC++, plus the
clean and rock solid design with the steve harris (R) guarantee...
bests,
martin
7:36 p.m.
On Tue, Mar 15, 2005 at 11:22:50PM +0100, martin rumori wrote:
hi arnold,
On Tue, Mar 15, 2005 at 09:12:19PM +0100, Arnold Krille wrote:
There was some months ago, as thats where liblo's pattern matching code
came from.
I had a look into Steve Harris' liblo and
libOSC++. The later seems more
appealing to me since I am a C++-Guy.
two years ago, i added the network classes (Inet*) to libOSC++, fixed
some bugs, cleaned up a bit... the library was used in different
projects (http://listen.gmd.de, http://www.grenzenlosefreiheit.de,
plus the wiretap thing of the original libOSC++ developers) and
appeared to be stable.
BUT: as far as i know, there is not much development ongoing at the
moment, and i ever planned some redesign for the whole library (i
don't consider using a std::string as container for an osc message as
a nice example for object oriented design...), but unfortunetaly there
wasn't enough time... just some background information concerning libOSC++.
be sure to pick
the "fraunhofer" branch if using it. there is a download page at
http://libosc.rumori.de
but i guess that liblo might be the better choice, it's in vivid
development and used by much more projects than libOSC++, plus the
clean and rock solid design with the steve harris (R) guarantee...
*cough* well the design may be ok in places, but the codebase is not
exactly bug-free :)
- Steve
7:51 p.m.
On Wednesday 16 March 2005 00:36, Steve Harris wrote:
On Tue, Mar 15, 2005 at 11:22:50PM +0100, martin
rumori wrote:
Hey, its from Code-Master Steve Harris, it has certainly less bugs than
anything I am ever to release ;-) (*)
I am not worthy, I am not worthy,...
Good night,
Arnold
(*) Perhaps not including this hello-world-app for the shell:
echo "Hello World";
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
but i guess that liblo might be the better
choice, it's in vivid
development and used by much more projects than libOSC++, plus the
clean and rock solid design with the steve harris (R) guarantee...
*cough* well
the design may be ok in places, but the codebase is not
exactly bug-free :) 
9:33 p.m.
On Tue, 2005-15-03 at 21:12 +0100, Arnold Krille wrote:
Hi all,
after some of the latest discussions about audio-apps without gui, my head is
filled with giving JackMix[1] OSC-Support and perhaps splitting it into a
text-based / osc-based server doing the mixing and a gui...
So my question arises: Which OSC-implementation to use?
I had a look into Steve Harris' liblo and libOSC++. The later seems more
appealing to me since I am a C++-Guy.
What do you folks think? What do you propose? What are you using?
Arnold
[1] http://roederberg.dyndns.org/~arnold/jackmix/
Definitely use liblo, no question. It's actually in active development
(libosc++ is stale as can be), and is generally the OSC library for
linux audio things to use (IMNSHO). In other words, most people have
it, or will soon enough (it's in Debian, and libosc++ is not, for the
record)
I use it for GUI->Engine (and back) communication, and all is well (and
yes, two clients can control the engine and see each others updates and
all that - it looks pretty cool ;] )
Plus, liblo is going to get ZeroConf service discovery and other such
shiny things Real Soon Now(TM)
-DR-
P.S. Death to MIDI! :)
16 Mar
16 Mar
5:15 a.m.
On Wed, Mar 16, 2005 at 12:24:55PM -0500, Dave Robillard wrote:
On Tue, 2005-15-03 at 21:12 +0100, Arnold Krille
wrote:
Ugh, I have a strong aversion to protocol implementation mono-culture. I
know there are some apps that have thier own OSC implementation or use
other libraries, but it will be a source of compatibility problems if
basicly all linux audio people end up using liblo. That was never my
intention when I wrote it, I just wanted C programmers to have a decent
option. Misguided C++ programmers can fend for themselves ;)
So my question arises: Which OSC-implementation
to use?
I had a look into Steve Harris' liblo and libOSC++. The later seems more
appealing to me since I am a C++-Guy.
What do you folks think? What do you propose? What are you using?
Arnold
[1] http://roederberg.dyndns.org/~arnold/jackmix/
Definitely use liblo, no question. It's actually in active development
(libosc++ is stale as can be), and is generally the OSC library for
linux audio things to use (IMNSHO). In other words, most people have
it, or will soon enough (it's in Debian, and libosc++ is not, for the
record) I use it for GUI->Engine (and back) communication,
and all is well (and
yes, two clients can control the engine and see each others updates and
all that - it looks pretty cool ;] )
Plus, liblo is going to get ZeroConf service discovery and other such
shiny things Real Soon Now(TM)
ZeroConf is certainly pretty neat.
P.S. Death to MIDI! :)
Well death-to-MIDI-in-software! thats a little less snappy though ;) Until
people start producing cheap OSC-speaking hardware were kinda stuck with
MIDI.
- Steve
6:56 a.m.
On Wed, 2005-16-03 at 09:15 +0000, Steve Harris wrote:
Well, yeah.. MIDI is quite suitable for a hardware interface IMO.
Binding numbers to physical knobs is okay - who wants to configure OSC
paths for knobs on some crappy little LED display? We'll just need a
nice external MIDI device -> OSC bridge app.
Death to MIDI in software it is then. DTMIS! For great justice!
-DR-
On Wed, Mar 16, 2005 at 12:24:55PM -0500, Dave
Robillard wrote:
Just recommending he use it, relax! ;)
Everyone using one protocol implementation has it's drawbacks, but
looking at it from the other perspective - why the heck would someone
write yet another OSC library? Linux isn't the only game in town
anyhow, and things like supercollider and pd (and..?) aren't switching
to liblo any time soon.
As for C++.. well, someone is eventually going to get really tired of
writing static mirror methods for every f(*#$(*$# callback and write C++
bindings. :]
On Tue, 2005-15-03 at 21:12 +0100, Arnold Krille
wrote:
Ugh, I have a strong aversion to protocol implementation mono-culture. I
know there are some apps that have thier own OSC implementation or use
other libraries, but it will be a source of compatibility problems if
basicly all linux audio people end up using liblo. That was never my
intention when I wrote it, I just wanted C programmers to have a decent
option. Misguided C++ programmers can fend for themselves ;) So my question arises: Which OSC-implementation
to use?
I had a look into Steve Harris' liblo and libOSC++. The later seems more
appealing to me since I am a C++-Guy.
What do you folks think? What do you propose? What are you using?
Arnold
[1] http://roederberg.dyndns.org/~arnold/jackmix/
Definitely use liblo, no question. It's actually in active development
(libosc++ is stale as can be), and is generally the OSC library for
linux audio things to use (IMNSHO). In other words, most people have
it, or will soon enough (it's in Debian, and libosc++ is not, for the
record) P.S. Death to
MIDI! :)
Well death-to-MIDI-in-software! thats a little less snappy though ;) Until
people start producing cheap OSC-speaking hardware were kinda stuck with
MIDI. 
12:04 p.m.
New subject: [linux-audio-dev] Hammerfall HDSP up for grabs guys
Hey guys,
I've got an RME Hammerfall HDSP 9652 up on grabs on ebay. Help me make
rent this month :). If you mention that you are on this list, being the
cool people that you are, I will refund you the shipping cost. Probably
some other things popping on there soon as well.
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=7308536378
Thanks,
Shane
4:56 p.m.
Hi,
I haven't tried it seriously, but there's also oscpack by Ross Bencina.
http://www.audiomulch.com/~rossb/code/oscpack/
Cheers,
Andrés
11:46 a.m.
Hallo!
after some of the latest discussions about audio-apps
without gui, my head is
filled with giving JackMix[1] OSC-Support and perhaps splitting it into a
text-based / osc-based server doing the mixing and a gui...
I'm just planning a
similar project, where the user can build a GUI and
can send OSC-messages with it to PD, supercollider, max, ...
(But it should mainly be used on a PDA - to make an _easy-to-use_ remote
control to various programs ...)
So my question: Are your plans very similar ? - (then I have to rethink
the whole stuff ...)
Just another question on the OSC implementation:
I planned to implement the application in Qt/C++ and wanted to ask, if
there could be troubles with liblo on a PDA (because I know that
libOSC++ was used on a PDA in http://www.grenzenlosefreiheit.de ) ?
Thanks in advance,
LG
Georg
12:40 p.m.
On Wednesday 16 March 2005 16:51, Georg Holzmann wrote:
No, certainly not. Mine is a real mixer for Jack...
Some of my plans are to make the mixer-backend pluggable to add for example a
gstreamer- or an arts- or an alsa-mixer backend.
My motivation is that most times you are using some synths and effects live
and everyone has its output-gain but there is no central gui to control their
gains or even split their output signals with different volumes to different
busses (like main-out and monitors).
after some of
the latest discussions about audio-apps without gui, my
head is filled with giving JackMix[1] OSC-Support and perhaps splitting
it into a text-based / osc-based server doing the mixing and a gui...
I'm just
planning a similar project, where the user can build a GUI and
can send OSC-messages with it to PD, supercollider, max, ...
(But it should mainly be used on a PDA - to make an _easy-to-use_ remote
control to various programs ...)
So my question: Are your plans very similar ? - (then I have to rethink
the whole stuff ...) Just another question on the OSC implementation:
I planned to implement the application in Qt/C++ and wanted to ask, if
Maybe we could join forces for an liblo-Qt-class?
Which timeframe are we talking about?
Arnold
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
17 Mar
17 Mar
7:17 a.m.
Hallo!
Maybe we could join forces for an liblo-Qt-class?
of course ... i would be very interested!
Which timeframe are we talking about?
My project
should be "finished" (or at least useable) in autumn this
year - some I have some time for it.
LG
Georg
Arnold
19 Mar
19 Mar
2:12 p.m.
On Wed, 2005-03-16 at 17:39 +0100, Arnold Krille wrote:
Maybe we could join forces for an liblo-Qt-class?
Which timeframe are we talking about?
Why a Qt class? A generic C++ implementation would probably be useful to
lots of other projects too.
--
Lars Luthman
PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
3:34 p.m.
On Sat, Mar 19, 2005 at 07:12:54PM +0100, Lars Luthman wrote:
On Wed, 2005-03-16 at 17:39 +0100, Arnold Krille
wrote:
I imagine it would bind the OSC method to Qt's control value class
(Adjustment in GTK speak).
- Steve
Maybe we could join forces for an
liblo-Qt-class?
Which timeframe are we talking about?
Why a Qt class? A generic C++ implementation would probably be useful to
lots of other projects too.
7:07 p.m.
On Saturday 19 March 2005 19:12, Lars Luthman wrote:
On Wed, 2005-03-16 at 17:39 +0100, Arnold Krille
wrote:
Because Qt rulez! ;-)
No, imho one of the main advantages is Qt's Signal/Slot mechanism and my
current implementation has come so far that I can send and receive OSC
messages with one argument (of type QVariant) via signals and slots.
These can be connected to whatever signals and slots one might think of (if
the number of arguments is the same) so this make the classes usable in other
projects without subclassing just by creating the objects and some
"connect( bla, blub)" lines.
For more see the source:
http://roederberg.dyndns.org/svn/apps/jackmix/osc/osc_client.h
http://roederberg.dyndns.org/svn/apps/jackmix/osc/osc_server.h
or the nightly build after these changes:
http://roederberg.dyndns.org/~arnold/file_share/jackmix/daily/jackmix-2005-…
Good night,
Arnold
BTW: For more usefulness of the server-class I will subclass it nonetheless...
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
Maybe we could join forces for an
liblo-Qt-class?
Which timeframe are we talking about?
Why a Qt class? A generic C++ implementation
would probably be useful to
lots of other projects too. 
7:23 p.m.
No, imho one of the main advantages is Qt's
Signal/Slot mechanism and my=20
current implementation has come so far that I can send and receive OSC=20
messages with one argument (of type QVariant) via signals and slots.
i don't want to get into a toolkit war, but gtkmm has been using
SigC++ since its inception, and although it was loosely inspired by
the Qt signal/slot system, it is widely acknowledged as superior to it
in almost every way. it even inspired the boost classes for
signals+slots, except that they forked it (so to speak) too early -
sigc++2 is just 100% pure C++ software engineering joy. sigc++ is
entirely independent of any graphical toolkit - you can use it
non-graphical applications as well.
projects without subclassing just by creating the
objects and some=20
"connect( bla, blub)" lines.
and using moc ... sigc++ doesn't require any preprocessor.
--p
20 Mar
20 Mar
10:16 a.m.
On Sat, 2005-03-19 at 17:24, Paul Davis wrote:
Same with Qt. It doesn't have to be graphical.
So? I never have to worry about what happens in the preprocessor.
I didn't write it and I don't have to debug it. It just works, and, it
just works cross platform. Now that Qt is releasing the Windows version
under GPL it will probably get a lot more use.
Having used both GTK and Qt I have to say that Qt is IMHO a much
more polished and mature package. I have yet to run into anything that
wasn't already anticipated by the Qt developers - QProcess, QPrinter,
QSocket, QFtp, QHttp, QBrowser... The one thing that annoys me about
it is that they didn't implement a double or float spinbox (I rolled my
own and they'll have one in 4.0 ;-) The documentation is also much
better. But that's just my opinion. I think that a lot of the choice
in which one you use is dependent on what you are programming. In
Paul's world he needs as much control and efficiency as possible.
Programming simpler applications doesn't require that kind of control -
witness QJackctl.
Jan
No, imho one of
the main advantages is Qt's Signal/Slot mechanism and my=20
current implementation has come so far that I can send and receive OSC=20
messages with one argument (of type QVariant) via signals and slots.
i don't want to get into a toolkit war, but gtkmm has been using
SigC++ since its inception, and although it was loosely inspired by
the Qt signal/slot system, it is widely acknowledged as superior to it
in almost every way. it even inspired the boost classes for
signals+slots, except that they forked it (so to speak) too early -
sigc++2 is just 100% pure C++ software engineering joy. sigc++ is
entirely independent of any graphical toolkit - you can use it
non-graphical applications as well.
projects
without subclassing just by creating the objects and some=20
"connect( bla, blub)" lines.
and using moc ... sigc++ doesn't require any preprocessor.
12:59 p.m.
sigc++2 is
just 100% pure C++ software engineering joy. sigc++ is
entirely independent of any graphical toolkit - you can use it
non-graphical applications as well.
Same with Qt. It doesn't have to be graphical. Having used both GTK and Qt I have to say that Qt
is IMHO a much
more polished and mature package. I have yet to run into anything that
wasn't already anticipated by the Qt developers - QProcess, QPrinter,
QSocket, QFtp, QHttp, QBrowser... The one thing that annoys me about
i completely agree with you. and my agreement is part of the reason
why i wouldn't want to use Qt. i don't believe that the list of
features you've just mentioned should be in a drawing toolkit - i'd
rather have a really great drawing toolkit *plus* another library (or
more than one) with support for these other cool (and useful)
things. your mileage may vary, of course.
i think that the decision to use Qt is a perfectly sensible one for a
lot of people - its just not the one i'd make.
--p
16 Mar
16 Mar
1:45 p.m.
On Wed, Mar 16, 2005 at 03:51:35 +0000, Georg Holzmann wrote:
Hallo!
It needs threads, so if the PDA's OS doesnt support pthreads it will be a
a pain.
- Steve
after some of the latest discussions about
audio-apps without gui, my head
is filled with giving JackMix[1] OSC-Support and perhaps splitting it into
a text-based / osc-based server doing the mixing and a gui...
I'm just planning
a similar project, where the user can build a GUI and
can send OSC-messages with it to PD, supercollider, max, ...
(But it should mainly be used on a PDA - to make an _easy-to-use_ remote
control to various programs ...)
So my question: Are your plans very similar ? - (then I have to rethink
the whole stuff ...)
Just another question on the OSC implementation:
I planned to implement the application in Qt/C++ and wanted to ask, if
there could be troubles with liblo on a PDA (because I know that
libOSC++ was used on a PDA in http://www.grenzenlosefreiheit.de ) ?
2:51 p.m.
On Wed, Mar 16, 2005 at 03:51:35PM +0000, Georg Holzmann wrote:
I'm just planning a similar project, where the
user can build a GUI and
can send OSC-messages with it to PD, supercollider, max, ...
Just another question on the OSC implementation:
I planned to implement the application in Qt/C++ and wanted to ask, if
there could be troubles with liblo on a PDA (because I know that
libOSC++ was used on a PDA in http://www.grenzenlosefreiheit.de ) ?
in libOSC++, you can switch off the pthread dependancy with a
configure-option. we (grenzenlosefreiheit.de) used it with polling
for osc-messages from the qt mainloop (for sure not ideal).
same remarks regarding libOSC++ as stated earlier when replying to
arnold.
we did some projects in which we used the zaurus as a control and
"remote mixer" for playbacks and performances. i did some helper
classes which i used in conjunction with qt signals and libOSC++,
originally with the same idea of extending the whole thing to a
flexible, user customizable gui... which never happened. just a few
classes written very quickly in "hot project situation". if you are
interested, i can send them off-list to you.
bests,
martin
17 Mar
17 Mar
7:21 a.m.
Hallo!
we did some projects in which we used the zaurus as a
control and
"remote mixer" for playbacks and performances. i did some helper
classes which i used in conjunction with qt signals and libOSC++,
originally with the same idea of extending the whole thing to a
flexible, user customizable gui... which never happened. just a few
I know - I
read the documentation (I also do it with Gerhard Eckel). So
if you have suggestions, or what should be improved please let me know ...
classes written very quickly in "hot project
situation". if you are
interested, i can send them off-list to you.
Yes please. This would be a great
help!
Thanks,
LG
Georg
7216
days inactive
7221
days old
linux-audio-dev@lists.linuxaudio.org
23 comments
11 participants
participants (11)
-
Andres Cabrera -
Arnold Krille -
Dave Griffiths -
Dave Robillard -
Georg Holzmann -
Jan Depner -
Lars Luthman -
martin rumori -
Paul Davis -
Shane -
Steve Harris