20 Jul
2006
20 Jul
'06
11:48 a.m.
On 7/20/06, Loki Davison <loki.davison(a)gmail.com> wrote:
On 7/20/06, Erik de Castro Lopo
<mle+la(a)mega-nerd.com> wrote:
You pretty much can't ever ask something about C++ without all the
haters coming out.
I've worked professionally using only C++ (and a little plain old C)
for 8 years, and the last 6 have been exclusively on Linux. Ocaml may
be programming nirvana, but it likely won't pay the bills, so I won't
be spending any time on it.
Loki Davison wrote:
I haven't tried ocaml. I should put it on the todo list. ;) I'm a bit
of a lisper and i find it easier to find places that let me program in
python than lisp/scheme, so it's a good back up plan. Jobs for both
are pretty damn hard to find though. :)
Loki
There are quite a few c++ 'not fans' on
LAD. C and python all the way ;)
I used to be a Python fan but for anything larger than a couple
of hundred lines I now prefer Ocaml.
Erik 
20 Jul
20 Jul
3:05 p.m.
New subject: [linux-audio-dev] [OT] Language fanboys [was Re: light C++ set for WAV]
I've worked professionally using only C++ (and a
little plain old C)
for 8 years, and the last 6 have been exclusively on Linux. Ocaml may
be programming nirvana, but it likely won't pay the bills
huh? i see job posts every week on nyc craigslist $130-150K OCaml programmers for large
investment house..
if you mean OCaml && audio, probably. there only room for so many 'tenured
developers' at CCRMA/CNMAT, eh..
7:05 p.m.
New subject: [linux-audio-dev] [OT] Language fanboys [was Re: light C++ set for WAV]
Paul Coccoli wrote:
You pretty much can't ever ask something about C++
without all the
haters coming out.
C++ has more big ugly warts that any other language I can think of.
I've worked professionally using only C++ (and a
little plain old C)
for 8 years, and the last 6 have been exclusively on Linux. Ocaml may
be programming nirvana, but it likely won't pay the bills,
I'm currently using Ocaml at work, but I also do C, C++, C#, Python
Actionscript and Verilog. I also have a friend who is doing a whole
bunch of distributed processing using Erlang, a language which is on
my "to learn" list.
I'm not so much a specific language fanboy as a languages fanboy.
There are so many languages out there that are outside the C, C++,
Java and C# bucket that offer features that people in the
C/C++/Java/C# camp don't even know about.
so I won't be spending any time on it.
Thats your choice, but 6 months learning Ocaml taught me more about
programming than I learned in the previous 5 years of a 10 plus
year programming career.
Being open to new tools, languages and techniques means that my
employer now considers me the guy who can be relied on to fix
anything that is actually fixable, regardless of whether I've
used it before.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Java sucks. C sucks slightly less so, but only because it makes
no pretense at all about being a high level language.
9:22 p.m.
New subject: [linux-audio-dev] [OT] Language fanboys [was Re: light C++ set for WAV]
I'm not so much a specific language fanboy as a
languages fanboy.
There are so many languages out there that are outside the C, C++,
Java and C# bucket that offer features that people in the
C/C++/Java/C# camp don't even know about.
I agree... Programming languages are amazing tools... just as natural
languages affects how we think, programming languages affect how we
code.
However, to bring this conversation back to a thread from a few weeks
ago, I find it interesting, and sometimes frustrating, that most new
languages that differ from C/C++ tend to target interpreters and
virtual machines.
Does anyone know any interesting and powerful languages that can be
used just like C? That can link to C libraries, and can be compiled to
native machine code, and can express the same low-level concepts as C,
but in a more powerful and intuitive way? In short, does anyone know
any languages other than C and C++ that would be interesting for audio
programming?
This list has made of aware of FAUST and some other interesting
examples of "meta-languages" that compile to C code. I do find this
interesting, but I would like a more common ground: something that can
be used in a more general-purpose way (like C), but is still useful
for audio, realtime programming, and maybe even operating systems
(like C).
I'm not one to argue against C or C++ actually, but having experienced
Python and other high-level languages, I find myself wanting to use
such a syntax for natively compiled code.
I suppose that one could argue that a lot of the power of these
interpreted languages comes from the fact that they are often
dynamically and loosely typed, which is much more difficult to express
in optimized, compiled code. It's precisely the strong typing and
well-defined memory usage that makes C useful for things like
operating systems and realtime programming. I do understand that. I am
only suggesting that maybe there is some middle-ground between the
likes of C and Python, that happens to not be C++. Anyone?
I have often wondered what I might do if I tried to design such a
language, but I think it's just too big a task. (For now anyways.)
And I would hate to re-invent the wheel yet again.
Steve
9:39 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On 7/21/06, Stephen Sinclair <radarsat1(a)gmail.com> wrote:
For music/audio stuff you can do the dsp stuff with c and then
communicate with another process written in a higher level language,
i.e python over OSC. The LAD irc crew have been discussing using this
idea for a new sequencer/daw thing.
Loki
I'm not so
much a specific language fanboy as a languages fanboy.
There are so many languages out there that are outside the C, C++,
Java and C# bucket that offer features that people in the
C/C++/Java/C# camp don't even know about.
I agree... Programming languages are amazing tools... just as natural
languages affects how we think, programming languages affect how we
code.
However, to bring this conversation back to a thread from a few weeks
ago, I find it interesting, and sometimes frustrating, that most new
languages that differ from C/C++ tend to target interpreters and
virtual machines.
Does anyone know any interesting and powerful languages that can be
used just like C? That can link to C libraries, and can be compiled to
native machine code, and can express the same low-level concepts as C,
but in a more powerful and intuitive way? In short, does anyone know
any languages other than C and C++ that would be interesting for audio
programming?
This list has made of aware of FAUST and some other interesting
examples of "meta-languages" that compile to C code. I do find this
interesting, but I would like a more common ground: something that can
be used in a more general-purpose way (like C), but is still useful
for audio, realtime programming, and maybe even operating systems
(like C).
I'm not one to argue against C or C++ actually, but having experienced
Python and other high-level languages, I find myself wanting to use
such a syntax for natively compiled code.
I suppose that one could argue that a lot of the power of these
interpreted languages comes from the fact that they are often
dynamically and loosely typed, which is much more difficult to express
in optimized, compiled code. It's precisely the strong typing and
well-defined memory usage that makes C useful for things like
operating systems and realtime programming. I do understand that. I am
only suggesting that maybe there is some middle-ground between the
likes of C and Python, that happens to not be C++. Anyone?
I have often wondered what I might do if I tried to design such a
language, but I think it's just too big a task. (For now anyways.)
And I would hate to re-invent the wheel yet again.
Steve 
10:13 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Fri, 21 Jul, 2006 at 09:39AM +1000, Loki Davison spake thus:
On 7/21/06, Stephen Sinclair
<radarsat1(a)gmail.com> wrote:
...
For music/audio stuff you can do the dsp stuff with c
and then
communicate with another process written in a higher level language,
i.e python over OSC. The LAD irc crew have been discussing using this
idea for a new sequencer/daw thing.
And I've been doing it with a small sample player. It works nicely
and means I don't have to deal with UI crud in C (nightmare!).
James
Loki
21 Jul
21 Jul
5:38 a.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Fri, Jul 21, 2006 at 01:13:43 +0100, james(a)dis-dot-dat.net wrote:
On Fri, 21 Jul, 2006 at 09:39AM +1000, Loki Davison
spake thus:
SooperLooper (http://essej.net/sooperlooper/) works that way and has done
for some time.
Some added bonuses are that your backend is inherantly scriptable from other
environments, and it pretty much forces you to adopt a MVC UI coding model.
- Steve
On 7/21/06, Stephen Sinclair
<radarsat1(a)gmail.com> wrote:
...
For music/audio stuff you can do the dsp stuff
with c and then
communicate with another process written in a higher level language,
i.e python over OSC. The LAD irc crew have been discussing using this
idea for a new sequencer/daw thing.
And I've been doing it with a small sample player. It works nicely
and means I don't have to deal with UI crud in C (nightmare!). 
12:18 a.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
1:31 a.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On 7/21/06, Thomas Vecchione <seablaede(a)gmail.com> wrote:
For music/audio stuff you can do the dsp stuff with c and then
communicate with another process written in a higher level language,
i.e python over OSC. The LAD irc crew have been discussing using this
idea for a new sequencer/daw thing.
Hmm this is interesting as I have been considering doing something
similar as well. I was wondering how much of a difference having a GUI
built in a non realtime style, either in an interpreted language or
similar setup, how this might affect things for audio use.
I was considering using OSC style communication between a backend
written in C/C++ and a GUI written in a seperate language.
Seablade
??? Non realtime style? How can you have a gui written in a real time
style? Doesn't that kind of break the basic rules of realtime?
Loki
1:46 a.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
??? Non realtime style? How can you have a gui written in a real time
style? Doesn't that kind of break the basic rules of realtime?
Well that is my question, sorry I should have clarified I am just now
getting into realtime programming so this might be a really stupid
question anyways. If you dont have the GUI thread(s) running at a high
priority, would that affect the overall response of the program?
Primarily I am looking at for triggering sound effects samples(Of
varying size) for live performance, thus I would need to make sure
response to the gui is also quick and that latency is not added in from
the time of hitting a "go" on screen.
Of course it might be very possible I am misunderstanding basic
principles behind realtime programming at any rate so please feel free
to just tell me Im stupid;)
Seablade
5:53 a.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Thu, Jul 20, 2006 at 09:51:05 -0700, Thomas Vecchione wrote:
The extent of that kind of latency is not quite so critical as processing
latency. What is important however is that the latency is constant, jitter
is quite obvious. Humans are able to correct for reasonably high constant
latency between actions and the sound happening. MIDI latency is typically
1ms or so, and that's generally not a issue. Getting lower than that in
a UI + OSC connection is no problem.
In any case, it's not a good idea to run GUI theads at high priority as
they often have to do actions which require a significant ammount of
wall-clock time.
If your thinking of using a UDPish protocol, please use OSC. The packet
format is a bit of a pig, but there are plenty of libraries that make it
easy (eg. http://liblo.sourceforge.net/) it means other peoples
software can interoperate with yours.
It will also save you a lot of time in debugging annoying network I/O
issues and platform dependencies.
- Steve
??? Non realtime style? How can you have a gui written in a real time
style? Doesn't that kind of break the basic rules of realtime?
Well that is my question, sorry I should have clarified I am just now
getting into realtime programming so this might be a really stupid
question anyways. If you dont have the GUI thread(s) running at a high
priority, would that affect the overall response of the program?
Primarily I am looking at for triggering sound effects samples(Of
varying size) for live performance, thus I would need to make sure
response to the gui is also quick and that latency is not added in from
the time of hitting a "go" on screen.
4:28 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
What is important however is that the latency is
constant, jitter
is quite obvious.
Makes sense, how often is jitter in that regards a problem and if it is
a decent amount of time, what might be done to help with that problem?
MIDI latency is typically
1ms or so, and that's generally not a issue.
Yea a ms or less definitely wouldn't be a problem for what I am thinking
of. I tend to think slightly higher might not be a problem either, but
I was worried it might get over, say 3 mS which I think might cause a
problem. This is overall between GUI and communication.
Getting lower than that in
a UI + OSC connection is no problem.
That is good to know and exactly answers my question I think, thanks.
In any case, it's not a good idea to run GUI
theads at high priority as
they often have to do actions which require a significant ammount of
wall-clock time.
Again thanks for the information.
If your thinking of using a UDPish protocol, please
use OSC.
Was definitely considering it. I suppose my question there might be,
while I don't have intentions for it currently, I don't want to rule out
the possibility of the FE running on a separate machine, and I would be
worried about packet loss with UDP over a network or possibly wireless
connection (Not looking for wireless for show conditions, more for say
in a theater show when I might be setting cue levels by running a FE on
my PDA). But yes OSC is definitely looking like a good possibility. Of
course I haven't looked to see if there is an OSC lib for my PDA much
less most PDAs;)
Seablade
7:01 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
Hallo,
Thomas Vecchione hat gesagt: // Thomas Vecchione wrote:
my PDA). But yes OSC is definitely looking like a
good possibility. Of
course I haven't looked to see if there is an OSC lib for my PDA much
less most PDAs;)
liblo runs on PDAs. Check out the asciimatrix by Martin Rumori and
Andreas Krach, for example their presentation at the Linux AUdio
Conference this year. asciimatrix uses liblo.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
7:29 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Fri, 2006-07-21 at 12:32 -0700, Thomas Vecchione wrote:
OSC can go over TCP to avoid the packet loss issue (and messed up
ordering which can be extremely annoying as well). liblo's TCP support
needs some work though.
-DR-
If your
thinking of using a UDPish protocol, please use OSC.
Was definitely considering it. I suppose my question there might be,
while I don't have intentions for it currently, I don't want to rule out
the possibility of the FE running on a separate machine, and I would be
worried about packet loss with UDP over a network or possibly wireless
connection (Not looking for wireless for show conditions, more for say
in a theater show when I might be setting cue levels by running a FE on
my PDA). But yes OSC is definitely looking like a good possibility. Of
course I haven't looked to see if there is an OSC lib for my PDA much
less most PDAs;) 
24 Jul
24 Jul
12:48 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
Hmm this is interesting as I have been considering
doing something
similar as well. I was wondering how much of a difference having a
GUI built in a non realtime style, either in an interpreted language
or similar setup, how this might affect things for audio use.
Do the engine in C. Do the GUI in C+libcairo/libcairo-svg/librsvg/libSDL.
SVG is incredibly easy to use for flexible, interesting, unique GUI
design and implementation. Describe the whole flow of your GUI
through the SVG DOM, and away you go ..
--
;
Jay Vaughan
1:25 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Mon, Jul 24, 2006 at 04:48:12PM +0200, Jay Vaughan wrote:
SVG is incredibly easy to use for flexible,
interesting, unique GUI
design and implementation. Describe the whole flow of your GUI
through the SVG DOM, and away you go ..
could you elaborate on that? any example usage/implementation?
thanks,
<sk>
1:33 p.m.
New subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
could you elaborate on that? any example
usage/implementation?
I'm using it to build a game for the GP2X .. with an engine in C,
plain ol' daemon mode, sending events to a GUI process for rendering
through the SVG DOM. When I'm ready to release the package (plus
source), I'll let you know ..
--
;
Jay Vaughan
21 Jul
21 Jul
7:38 a.m.
New subject: [linux-audio-dev] [OT] Language fanboys [was Re: light C++ set for WAV]
Stephen Sinclair wrote:
Does anyone know any interesting and powerful
languages that can be
used just like C? That can link to C libraries, and can be compiled to
native machine code, and can express the same low-level concepts as C,
but in a more powerful and intuitive way? In short, does anyone know
any languages other than C and C++ that would be interesting for audio
programming?
As SuperCollider and ChucK show, being interpreted and dynamically typed
doesn't preclude lowlat realtime audio work. I'd also like to mention my
own brainchild Q (http://q-lang.sf.net), a general-purpose functional
programming language which interfaces nicely to MidiShare, Faust and
(via OSC) SuperCollider and is certainly usable for doing soft realtime
stuff for audio and computer music applications.
I have often wondered what I might do if I tried to
design such a
language, but I think it's just too big a task.
You can bet on that. :) Faust, ChucK and SuperCollider are all
domain-specific languages which makes the task somewhat simpler. There's
no doubt that creating a very-high-level language, which supports *both*
lowlat signal processing and general-purpose programming equally well,
will be a major undertaking which still needs a considerable amount of
research. One might argue that modern-style FPLs like Ocaml and Haskell
are almost there, but AFAICS they still lack realtime-capable
multithreading and decent multimedia interfaces. And we need more brave
souls like Erik who are willing to stray away from the traditional paths
and give those new languages a chance. ;-)
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.musikinformatik.uni-mainz.de/ag
6643
days inactive
6647
days old
linux-audio-dev@lists.linuxaudio.org
17 comments
13 participants
participants (13)
-
Albert Graef -
carmen -
Dave Robillard -
Erik de Castro Lopo -
Frank Barknecht -
james＠dis-dot-dat.net -
Jay Vaughan -
Loki Davison -
Paul Coccoli -
stefan kersten -
Stephen Sinclair -
Steve Harris -
Thomas Vecchione