hi mimo,
are you thinking of something like buzz (or maybe max/msp) where audio
can be routed in a free-form network from sources (generators) to sink
(master output)? i'm a big fan of this idea.
the Preprocessor Level that lazily generates a set optimised list of
instructions for the audio
Hi James,
James McDermott wrote:
hi mimo,
are you thinking of something like buzz (or maybe max/msp) where audio
can be routed in a free-form network from sources (generators) to sink
(master output)? i'm a big fan of this idea.
You got me! I am a long term buzz user, used it for live gigs, and
it all sounds a lot like Beast to me ...
http://beast.gtk.org/
--p
Hi Mimo,
I have put online the beginngs of a concept paper for an audio program I
have been wanting to write for quite a while now. I wondered whether you
could give me some feedback on it and share some of your experiences
with me. A while ago I decided to call this *mux* where the name stands
Walco wrote:
Hi Mimo,
PS.: the paper is here http://mimo.gn.apc.org/mux/
First of all: nice initiative. But...
...why create a new modular audio framework, if you could
improve, harden and extend an existing one? Think of all that hairy GUI
code that you don't have to write and debug...
Well and
You got me! I am a long term buzz user, used it for live gigs, and wrote
a keyboard based mixer for it.
oh - you wrote miXo - of course. (i wrote a peer machine or two.) go buzz devs!
i think everyone who's ever used buzz for more than a couple of hours
wants a new, stable, cross-platform
Walco wrote:
Hi Mimo,
I have put online the beginngs of a concept paper for an audio
program I have been wanting to write for quite a while now. I
wondered whether you could give me some feedback on it and share some
of your experiences with me. A while ago I decided to call this *mux*
where
on the subject of beast (and maybe some other programs), i'd agree
that it's cpu-intensive. the great thing about buzz (sorry for going
on about it) is that it's fast: songs using 50+ plugins are possible
on old machines, like my 566 MHz celeron laptop.
I know it was a bit provocative to write that. Also, jack is under
development and I should probably wait for an official release before
this is not really true. there have been no API changes to the core of
JACK for at least a year.
complaining. But my experiences with jack are negative.
Dave Phillips wrote:
Btw, mimo: Have you tried using Buzz under Linux ? I've had it working
quite nicely, it's a very impressive program, lots of fun. A native Buzz
would be most welcome.
I guess you mean under wine. I have but wasnt impressed with performance
(maybe I really should get a
Paul Davis wrote:
complaining. But my experiences with jack are negative. First time I
started looking at it I had huge expectations after all that I had read.
First problems, after a couple of second of running without any
actual processing going on, strange noise artefacts kind of getting
On Thu, Feb 17, 2005 at 08:40:01AM -0500, Paul Davis wrote:
you can have absolute minimal latency, but that requires
locking the graph against use when it is reordered.
AFAICS, that is not the real reason. If it were, the simple
solution would be to let the engine continue using a copy
of the
On Thu, Feb 17, 2005 at 02:00:24 +, mimo wrote:
Paul Davis wrote:
complaining. But my experiences with jack are negative. First time I
started looking at it I had huge expectations after all that I had read.
First problems, after a couple of second of running without any
actual
Just out of interest, if it is dependent on the audio hardware, why do I
get the same problems with different sounds cards on the same machine,
and a colleague gets them with completely different hardware all the
same. Any ideas what might be the reason? Anyone else with the same
experiences?
you can have absolute minimal latency, but that requires
locking the graph against use when it is reordered.
AFAICS, that is not the real reason. If it were, the simple
solution would be to let the engine continue using a copy
of the current graph while the new one is being computed and
the
Steve Harris wrote:
On Thu, Feb 17, 2005 at 02:00:24 +, mimo wrote:
Paul Davis wrote:
complaining. But my experiences with jack are negative. First time I
started looking at it I had huge expectations after all that I had read.
First problems, after a couple of second of running without any
Le 17 févr. 05, à 15:26, Alfons Adriaensen a écrit :
On Thu, Feb 17, 2005 at 08:40:01AM -0500, Paul Davis wrote:
you can have absolute minimal latency, but that requires
locking the graph against use when it is reordered.
AFAICS, that is not the real reason. If it were, the simple
solution would
Le 17 févr. 05, à 15:43, Paul Davis a écrit :
you can have absolute minimal latency, but that requires
locking the graph against use when it is reordered.
AFAICS, that is not the real reason. If it were, the simple
solution would be to let the engine continue using a copy
of the current graph
On Thu, Feb 17, 2005 at 09:43:16AM -0500, Paul Davis wrote:
stephane's new OSX implementation (jackdmp) avoids both of these, and
ends up with an extra process-cycle worth of latency. he does exactly
what you suggest above. is it avoidable? i don't know. stephane didn't
seem to think so when
On Thu, 2005-02-17 at 09:39 -0500, Paul Davis wrote:
Just out of interest, if it is dependent on the audio hardware, why do I
get the same problems with different sounds cards on the same machine,
and a colleague gets them with completely different hardware all the
same. Any ideas what
On Thu, 2005-02-17 at 08:40 -0500, Paul Davis wrote:
complaining. But my experiences with jack are negative. First time I
started looking at it I had huge expectations after all that I had read.
First problems, after a couple of second of running without any
actual processing going on,
On Thu, Feb 17, 2005 at 02:45:22 +, mimo wrote:
Are you running it in realtime mode? If not, and jackd misses realtime
deadlines you will often get noises in the output.
Yes, and root, tried evryting I could think of. And again, this happens
without any load.
Is the card a soundblaster
On Thu, Feb 17, 2005 at 11:20:06 -0500, Lee Revell wrote:
this has nothing to do with your noise. JACK uses CPU Hz to provide a
UST value. i am puzzled by the fact you are the 2nd person to think
that JACK's timing is somehow based on system timers and so
forth. JACK (in regular mode,
Lee Revell wrote:
On Thu, 2005-02-17 at 09:39 -0500, Paul Davis wrote:
Just out of interest, if it is dependent on the audio hardware, why do I
get the same problems with different sounds cards on the same machine,
and a colleague gets them with completely different hardware all the
same. Any
On Thu, 2005-02-17 at 16:33 +, Steve Harris wrote:
Besides, I wrote a patch to eliminate the /proc/cpuinfo hack, it's low
prio but should be in JACK eventually. But like Paul says this has
absolutely nothing to do with the sound.
Actually it can be on laptops with CPU scaling. JACK
Every time I start qjackctl from a remote X session I get these errors
at startup. I am using the Cygwin X server.
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 2
Minor opcode: 0
Resource id: 0x3a
X Error: BadAtom (invalid Atom parameter) 5
Major opcode: 18
Minor
Can you log in to the remote system using ssh -Y? This looks like one of the
X11Forwarding problems.
Jan
On Thu, 17 Feb 2005 13:11 , Lee Revell [EMAIL PROTECTED] sent:
Every time I start qjackctl from a remote X session I get these errors
at startup. I am using the Cygwin X server.
X Error:
On Thu, 2005-02-17 at 05:40, Dave Phillips wrote:
Walco wrote:
Hi Mimo,
I have put online the beginngs of a concept paper for an audio
program I have been wanting to write for quite a while now. I
wondered whether you could give me some feedback on it and share some
of your
Hi Fernando:
I built PortAudio (v19 I believe) with ALSA and JACK support but I
haven't used it with JACK at all. When building Cs5 Scons will assume
your PortAudio has been built with JACK, you need to specify if it isn't.
Best,
dp
On Thu, 2005-02-17 at 05:40, Dave Phillips wrote:
Walco
Lee Revell wrote:
Every time I start qjackctl from a remote X session I get these errors
at startup. I am using the Cygwin X server.
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 2
Minor opcode: 0
Resource id: 0x3a
X Error: BadAtom (invalid Atom parameter) 5
libDSP is a C++ library of digital signal processing functions with
class and template interface. It also has a wrapper for C language. It
also has assembler optimizations for x86 (E3DNow! and SSE2) and x86-64
platforms.
Changes:
- Assembler optimized version of complex multiply-add has been
I've touched on the concept. I started out with the same paper and desires,
and ended up with pkaudio.
PKAudio - simple, practical API, powerful, takes care of asynchronous
communication.
http://pkaudio.sf.net/
On Thursday 17 February 2005 03:22 am, James McDermott wrote:
hi mimo,
are you
On Thu, 2005-17-02 at 13:07 +, mimo wrote:
Walco wrote:
Hi Mimo,
PS.: the paper is here http://mimo.gn.apc.org/mux/
First of all: nice initiative. But...
...why create a new modular audio framework, if you could
improve, harden and extend an existing one? Think of all
I've been banging my head against this one all evening. Now I'm going to
go to sleep on it, but I throw it out for the wiser and more experienced
to see if you can see my error.
The code is at http://fugal.net/~fugalh/src/alex which you are welcome
to refer to and critique.
It segfaults on line
34 matches
Mail list logo
