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 di
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 whee
> 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 a
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 AP
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.
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
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
In source/lang/langPrimSource:
PyrFilePrim.cpp:31: added line #include
PyrUnixPrim.cpp:31: added line #inclu
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 cho
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 the
> 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
>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
widge
> -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.
> >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
> 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
> 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
er
>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 solut
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 profession
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 c
> 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, us
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 pre
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
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 somet
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 w
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
Http:
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
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 people
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
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 it's
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
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
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 lo
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 h
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
On Thu, Oct 17, 2002 at 12:02:34 -0400, Dave Phillips wrote:
> Steve Harris wrote:
>
> > I'm trying to build it on gcc2.96, I got some random libtool error, which I
> > made go away with ./ltconfig ltmain.sh. Its still not working though.
>
> Steve, do let us know if you succeed. I have the same
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 be
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, wor
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 mor
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 a
"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 i
39 matches
Mail list logo
