Paul Davis [EMAIL PROTECTED] wrote:
thats very true. my position is very, very simple: OSS was a *HUGE*
and monstrous mistake. in the guise of using The Unix Way (TM) for an
audio API, it has saddled us with dozens of (mostly toy) applications
that use a design model/architecture that is not
On Thu, Oct 17, 2002 at 09:49:53 +0100, nick wrote:
No, there is no real instrument or synth plugin API. but since my
original post I have been brewing something up. its quite vst-like in
some ways, but ive been wanting to make it more elegant before
announcing it. It does, however, work, and
On Thu, Oct 17, 2002 at 05:00:39 -0400, Paul Davis wrote:
i think you need to scan back a year or 18 months in the archives to
where we measured this. the context switch under linux can be
extremely quick - on the order of 20-50 usecs on a PII-450, and is not
Do we know if this is getting
On Fri, Oct 18, 2002 at 12:52:45 +1000, Conrad Parker wrote:
I work with a small community radio station, and since we're continually
strapped for cash we implement our studio-transmitter link by streaming
audio over a network. We use a variety of players and formats (mainly xmms
and
On Thu, Oct 17, 2002 at 03:03:03 -0700, Joshua Haberman wrote:
Let me take a step back and ask a question that has plagued me for a while:
what *is* the Unix way to solve new problems in new domains?
FWIW I think Paul was overstating the case. Its true that open/read/write
is not viable for low
Title: Dear Friend
Dear Friend,
We would like to introduce ourselves
Creativeskulls, We are a new media concern having a setup of 11 high end
workstations. We are looking for business partners/clients who are interested in
offloading their work. Our rate is only 5 US$ for an hour of
From: Steve Harris [EMAIL PROTECTED]
Hmmm... My experiments with c++, dsp code and gcc (recent 2.96) did not
turn out very well. For some reason the optimiser totaly chokes on c++
code. I only tried one routine, and I'm no c++ expert, so its possible I
screwed something up, but it did not
Richard Bown wrote:
On Friday 18 October 2002 09:23, Richard Bown wrote:
it's time that there was a clear distinction between Linux Sound/Audio
and Linux for Music. The latter has a clearly defined marketplace,
the former doesn't.
Sorry, that's not quite right. The former does too, but
On Fri, Oct 18, 2002 at 12:44:56 +, Stefan Nitschke wrote:
Hmmm... My experiments with c++, dsp code and gcc (recent 2.96) did not
turn out very well. For some reason the optimiser totaly chokes on c++
code. I only tried one routine, and I'm no c++ expert, so its possible I
screwed
Patrick Shirkey wrote:
While I was in Thailand I spent most of my time pondering how to make
more impact. I have a few ideas which require serious investment of my
time and energy.
One of my ideas was to get a community fund for advertising in the
correct publications.
I know several
On Friday 18 October 2002 13:51, Patrick Shirkey wrote:
I see your point. But feel that the problem is not that it is too
difficult or ugly for the majority of people but that we have not
done a good enough job of showing how worthwhile it is to spend long
hours on figuring out how to get the
Patrick Shirkey wrote:
I am willing to collate this information and write it up into an
official site and document (no prob for me these days).
http://www.djcj.org/LAU/openads/
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Steve Harris wrote:
Hmmm... My experiments with c++, dsp code and gcc (recent 2.96) did not
turn out very well. For some reason the optimiser totaly chokes on c++
code. I only tried one routine, and I'm no c++ expert, so its possible I
screwed something up, but it did not look encouraging. I will
On Fri, Oct 18, 2002 at 01:39:13 +0200, Tim Goetze wrote:
Hmmm... My experiments with c++, dsp code and gcc (recent 2.96) did not
turn out very well. For some reason the optimiser totaly chokes on c++
code. I only tried one routine, and I'm no c++ expert, so its possible I
screwed something
On Fri, Oct 18, 2002 at 02:55:28 +0100, Richard Bown wrote:
I see your point. But feel that the problem is not that it is too
difficult or ugly for the majority of people but that we have not
done a good enough job of showing how worthwhile it is to spend long
hours on figuring out how to
On Friday 18 October 2002 15:49, Steve Harris wrote:
Notice the future tense. I dont think its a good idea now, better to
wait 'til we have a nice bunch of jack'd (+ alsa midi/whatever),
stable, documented apps, all playing well together than put people
off with the kind of stuff we're
Things like jack have to be graphically wrappered or hidden too, no
scrolling text windows of xruns. The occasionaly discussed jack session
saving gizmo would be a knock dead feature.
mmm a jack controller app that you could configure (with a mouse) start jack
and check the current state, use
On Fri, Oct 18, 2002 at 04:50:18 +0100, Dave Griffiths wrote:
Things like jack have to be graphically wrappered or hidden too, no
scrolling text windows of xruns. The occasionaly discussed jack session
saving gizmo would be a knock dead feature.
mmm a jack controller app that you could
On Fri, Oct 18, 2002 at 04:49:43 +0100, Richard Bown wrote:
We launched RG from a desktop icon all last week. It now has
Logic-style status messages on the splash screen while you're waiting
for it to start and (while they can be a little naff) touches like that
are give it a professional
Maybe, but the people I'm thinking of are looking for a replacement for
thier protools+logic systems, not cubase or cakewalk.
Home users are important too, but...
It's probably up to the bread and butter products to drive the bespoke,
studio-end products. The complete, finished solution that
I think gcc is in general not the best choice when you want to have highly
optimized code. I had no problems with C++ so far. You should avoid to use
pointers when ever possible and use references instead. RTSynth is written
in C++ and it performs quite well i think...
- Stefan
erm,
Until we have such instrument plugin API, what is the
right way to implement the the system
(30 softsynths working together)
with what we have
I mean a bunch of software synths /dev/midi - /dev/dsp
Can I use these together right now?
oh yeah, you need to use ALSA though i think youll
This discussion is open!
the discussion is several years old :)
and it doesnt look set to end anytime soon ;-)
you managed to touch upon the central problem in your penultimate
sentence, apparently without realizing the depth of the problem.
if a synth comes with a GUI, then the issue
-Original Message-
From: nick [mailto:nixx;nixx.org.uk]
I think gcc is in general not the best choice when you want
to have highly
optimized code. I had no problems with C++ so far. You
should avoid to use
pointers when ever possible and use references instead.
RTSynth is
but personally i find it much more desirable that the plugin provides
effectively a widget which can be added to a container (provided by the
host) rather than the plugin creating its own window. its just much
neater..
this makes no difference to the problem. whether the plugin creates a
widget
Things like jack have to be graphically wrappered or hidden too, no
scrolling text windows of xruns. The occasionaly discussed jack session
saving gizmo would be a knock dead feature.
And any offering to the general public that doesn't contain this feature
will probably end up just plain
erm, sorry, but why not use pointers?
Just out of couriosity i made a benchmark test between C and C++ with
gcc3. I dont have a clue abour x86 assembler so i made a measurement.
Here is the C code (not realy useful as real code would have a need for a
struct and a pointer operation to call
On Thu, 2002-10-17 at 22:00, Paul Davis wrote:
thus guaranteeing that no instruments can be written in other
languages. for all the mistakes the GTK+ crew made, their design to
use C as the base language so as to allow for other languages to
provide wrappers was a far-sighted and wise choice.
I got it compiled with gcc-2.96 - all it needed was a few includes and
some other things. Here's a full list of what I had to do:
In source/server:
SC_CoreAudio.cpp:31: added line #include algorithm
In source/lang/langPrimSource:
PyrFilePrim.cpp:31: added line #include stdio.h
PyrUnixPrim.cpp:31:
Stefan Nitschke wrote:
erm, sorry, but why not use pointers?
Just out of couriosity i made a benchmark test between C and C++ with
gcc3. I dont have a clue abour x86 assembler so i made a measurement.
Here is the C code (not realy useful as real code would have a need for a
struct and a
Hi,
I am a musician and also a programmer. I have many years experience of
coding but not in the audio field. Any tuts around? How do I get into
it?
Cheers for any info.
-Lea.
On Sat, Oct 19, 2002 at 12:29:15AM +0100, Lea Anthony wrote:
Hi,
I am a musician and also a programmer. I have many years experience of
coding but not in the audio field. Any tuts around? How do I get into
it?
Cheers for any info.
-Lea.
Lea,
I suggest you use the Jack API when
On Thu, 2002-10-17 at 22:00, Paul Davis wrote:
thus guaranteeing that no instruments can be written in other
languages. for all the mistakes the GTK+ crew made, their design to
use C as the base language so as to allow for other languages to
provide wrappers was a far-sighted and wise
On 19 Oct 2002 00:29:15 +0100
Lea Anthony [EMAIL PROTECTED] wrote:
Hi,
I am a musician and also a programmer. I have many years experience of
coding but not in the audio field. Any tuts around? How do I get into
it?
Basic idea is to save yourself time by not re-inventing the wheel.
On Friday 18 October 2002 04:25, Patrick Shirkey wrote:
My opinion is that there is not enough people working on the
promotional side of ALSA and Linux Audio.
ALSA/LAD is too geeky and too die-hard techno hardcore to appeal to
anyone but geeks. IMHO music geeks are the worst type of geeks
On Friday 18 October 2002 09:23, Richard Bown wrote:
it's time that there was a clear distinction between Linux Sound/Audio
and Linux for Music. The latter has a clearly defined marketplace,
the former doesn't.
Sorry, that's not quite right. The former does too, but it's just a
little more
On Fri, Oct 18, 2002 at 09:23:11 +0100, Richard Bown wrote:
The point is that selling Linux Audio isn't just about Linux Audio -
it's about selling the whole desktop. It's about letting people know
that if they want to make music they can just get on and make music.
People shouldn't have
37 matches
Mail list logo
