Hi.
On 17 Oct 2002, nick wrote:
Hi
IMO running each synth in its own thread with many synths going is
definitely _not_ the way forward. The host should definitely be the only
process, much how VST, DXi, pro tools et. al. work.
No, there is no real instrument or synth plugin API. but since
On Fri, 2002-10-18 at 11:16, Paul Davis wrote:
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
On Fri, Oct 18, 2002 at 11:37:46 -0700, Josh Green wrote:
Please enlighten me, what was the problem then with multiple GUI
toolkits? IIRC it had to do with not being able to integrate multiple
applications together very well (at least as far as the user interface).
Its to do with the X event
On Fri, Oct 18, 2002 at 08:34:20 +0100, nick wrote:
indeed, for a plugin soft-synth, it would only ever make sense to write
it in c/c++ or assembler really, a question of speed. Are there really
people who seriously want to write a synth in aynthing else?
Of course, plenty of MacOS audio
On Fri, Oct 18, 2002 at 06:47:15 +, Stefan Nitschke wrote:
-O3 with C is broken, i got an endless loop!
What gcc version? What flags did you use with C?
The test I did had the C code using a struct, and I used the . syntax for
c++ method calls FWIW. I'l dig out the code in a min.
I think
On Fri, Oct 18, 2002 at 06:47:15 +, Stefan Nitschke wrote:
-O3 with C is broken, i got an endless loop!
What gcc version? What flags did you use with C?
I used gcc 3.2 that comes with SuSE 8.1.
Today i changed the initial values to a=0.5; b=0.001; x=0.1; and now
-O3 works!?? Here are
On Sat, 2002-10-19 at 00:49, Jack O'Quin wrote:
The main drawback to using C++ subroutine linkage in today's Linux
environment is the unstable ABI. This has caused many problems when
trying to call binary libraries built using different compilers or
sometimes even different compiler options.
are different versions of gcc3 ABI - compatible?
AFAIK all versions of gcc3 except version 3.0 which had a bug are
compatible.
- Stefan
_
Surf the Web without missing calls! Get MSN Broadband.
On Sat, Oct 19, 2002 at 09:45:32 +, Stefan Nitschke wrote:
The test I did had the C code using a struct, and I used the . syntax for
c++ method calls FWIW. I'l dig out the code in a min.
I think it was loop unrolling that was crappy in c++.
That would be a bad thing.
But by the look
Steve Harris wrote:
On Fri, Oct 18, 2002 at 08:34:20 +0100, nick wrote:
indeed, for a plugin soft-synth, it would only ever make sense to write
it in c/c++ or assembler really, a question of speed. Are there really
people who seriously want to write a synth in aynthing else?
Of course,
On Sat, Oct 19, 2002 at 11:55:09 -0400, David Gerard Matthews wrote:
Of course, plenty of MacOS audio software is written in Max/MSP (a
relative of pd). There is also some Windows software written in Sync -
both are graphical languages.
Although all the actual DSP objects themselves in MSP
STEFFL, ERIK (SBCSI) wrote:
erm, sorry, but why not use pointers
it's dangerous... null pointers, memory leaks etc. tendency is not to use
pointers unless absolutely neccessary...
References in C++ are just pointers in a sugared form. Actually they are
the same thing in a slightly
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
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
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
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
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
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.
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
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
Guys,
This answer appeared just after I decided to ask the very same question.
Is it true that there is no _common_ instrument or synth plugin API on linux?
Is it true that there is no the same kind of media for out-of-process instruments?
I see that there are some kinds of possible plugin
Hi
IMO running each synth in its own thread with many synths going is
definitely _not_ the way forward. The host should definitely be the only
process, much how VST, DXi, pro tools et. al. work.
No, there is no real instrument or synth plugin API. but since my
original post I have been brewing
IMO running each synth in its own thread with many synths going is
definitely _not_ the way forward. The host should definitely be the only
process, much how VST, DXi, pro tools et. al. work.
i think you need to scan back a year or 18 months in the archives to
where we measured this. the context
Paul Davis [EMAIL PROTECTED] writes
switching between contexts is massively more
expensive under windows and macos (at least pre-X),
As a data point, I ran two different sa.c files (the audio
engines sfront produces) set up as softsynths using different
patches under OS X (using CoreAudio +
On Thursday 17 Oct 2002 21:49, nick wrote:
Hi
IMO running each synth in its own thread with many synths going is
definitely _not_ the way forward. The host should definitely be the only
process, much how VST, DXi, pro tools et. al. work.
No, there is no real instrument or synth plugin API.
--- Paul Davis wrote:
IMO running each synth in its own thread with many synths going is
definitely _not_ the way forward. The host should definitely be the only
process, much how VST, DXi, pro tools et. al. work.
i think you need to scan back a year or 18 months in the archives to
where we
Oh yeah I forgot!
And there's another question I _realy_ want to know the answer for:
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
nick wrote:
Now somebody please put me straight here - as far as I can see, there's
LADSPA and JACK. (and MuSE's own plugins?). Now, I'm under the
impression that these only deal with the audio data - only half what I
need for a synth. Or can LADSPA deal with MIDI?
[...]
I just want to get
Hi all
I've been scratching my head for a while now, planning out how im going
to write amSynthe (aka amSynth2)
Ideally i don't want to be touching low-level stuff again, and it makes
sense to write it as a plugin for some host. Obviously in the Win/Mac
world theres VST/DXi/whatever - but that
Now somebody please put me straight here - as far as I can see, there's
LADSPA and JACK. (and MuSE's own plugins?). Now, I'm under the
impression that these only deal with the audio data - only half what I
need for a synth. Or can LADSPA deal with MIDI?
So how should I go about it?
Is it
On Thu, 2002-07-04 at 00:06, Paul Davis wrote:
You handle MIDI I/O in its own thread. You use a lock-free
buffer/fifo/queue between this thread and the one that executes
process() (or LADSPA's run()) callback. The queue should contain an
abstract description of recent MIDI events, preferably
38 matches
Mail list logo
