Wondering if anyone on hear is interested in working with me on my c/c++
front end for real time improvisation using csound5 as the audio engine.
The concept in a nutshell is like a cross between say Doepfer step
sequencers ( or Softwerk ) and Ableton live, except multi user and
designed for
i've experiencing some problems with the delayorama plugin ...
if the (feedback * taps) is bigger than 100, there is a big possibility
of clipping / sound getting louder and lounder / the plugin getting
unstable (???)...
i'd suggest to post a warning to stdout or stderr that the plugin will
get
the main differences from before is that it will have a compiler inside
and that it will be a multiuser environment.
also i'm not going to be the only mantainer of the only branch
available: there will be more dyne: versions.
actually the first branch out of dyne:II is the pure:dyne project
I use ecasound whenver I'm going to do the same batch of things to a
bunch of recordings. I'll be using for a quickdirty
restoration/remastering contract next month.
'Course I'm really only semi-pro. Some months I'm pro, some months I'm
not. ( Right now it's good, knock on wood! ) ;)
Iain
In realtime critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (30 microseconds worst case scheduling latency on recent x86
hardware).
I've often wondered about that. Why are those sorts of
Me too. It worked great on both my ancient laptop and my desktop, though
I did have to modprobe snd-usb-audio to get my usb midi box detected.
I've been raving about it to everyone. It also is incredibly easy to
customize.
jaromil wrote:
On Tue, Jun 14, 2005 at 09:33:45AM -0500, Andres
Aha, thanks Lee and Paul, that explains that!
Iain.
Lee Revell wrote:
On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
In realtime critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (30
Can you quantify how high-resolution you need, i.e. what accuracy?
The Linux kernel does not have support (yet) for resolution above
100Hz or 1000Hz, depending on your hardware platform.
There is some work going on into high resolution timers patches, but
integration of that is still far off I
Anyone have a good suggestion for a tutorial for making accurate
high-resolution high-priority clocks in C? I found some tutorials but
they were kinda old, so wondered if they might be out of date as to how
far real-time scheduling has come on linux. I want to be able to wake up
a pthread very
If you consider the buffer size to be the control rate, then that makes
sense. You don't want to be updating control information as much as
audio information if you want things to run at all quickly. Ie, and lfo
just doesn't need to be audio rate unless it's being used for fm or am
or really
That's cool! This is not meant to blow our own horns, but rather let
people know we're available. XORNOT ( myself and Glyn Gibson ) also do a
csound linux only live techno show. We just did our third set last
week here in Vancouver, using Csound5 ( yup that would include your work
Erik! ) and
Hi, wondering if this might tickle anyone's fancy on the agnula team.
The agnula live cd is a great idea. I would love to be able to customize
that however, to add my own apps, and of course data files. I play live
shows using csound5, but would like to add jack, jammin, ladspa plugins
etc,
I should have mentioned that I'm certainly interested in any other
non-agnula live cd solutions as well.
Thanks
Iain
As far as I see it, we'll at least get listened to by Con, Ingo and
Andrew Morton. I've had a long discussion with Con recently and from his
point of view, the problem is that not enough people ask (loud enough)
for such features. For instance, I'm still the first and only user of
his real-time
I'm serious, mailing lists are not enough. We need a permanent page with
instructions on making the noise so that the people who are *not yet*
fully jumping ship to linux can say to the developers, that is what
will make me abandon OSX. Those people aren't on mailing lists yet but
they still
Why do you want letters from project maintainers only? Don't you want
user letters as well?
Iain
Jean-Marc Valin wrote:
If someone sets up this forum, and more than twice of us sign
up, that should show those arrogant lklm-people that there are really
_a lot_ of us, and that we are strong, and
So essentially what you're saying is MIDI groove isn't really a
well-defined thing, just a catch-all phrase for humanization/groove
techniques in sequencers and whatnot.
yes.
Just out of curiousity, what gui library did you use for softwerk, and
if you were to do it over again, would you still use the same one? I'm
i used gtk--, a C++ thin wrapper of GTK+. i would use it again.
If I may ask you and others on here, how does this stack up against
fltk? I'm going to be
Well, since SOMEONE has to pipe up and say Pd can do it, might as well
be me. :)
Pd with GEM is pretty cool as far as visualization goes. Far better
than anything I've ever seen or heard of actually, because you can
visualize MIDI any way you want, which has waaay more potential than
visualizing
There's a /lot/ more information available in a MIDI performance, so the
potential to do interesting things is greater. Flash the screen
whenever the kick drum goes, have notes represented on screen as 3D
objects using frequency for location, filter cutoff controlling
lighting, blah blah etc.
a MIDI patch bay with extreme features (MIDI data filtering,
rechannelization, event mapping, etc)
Something like the above with a Snd style scripting language would be
hella cool.
Iain
The beginnings to some of these things are already available, so you'd
have a leg up on getting started.
Well, since SOMEONE has to pipe up and say Pd can do it, might as well
be me. :)
Pd with GEM is pretty cool as far as visualization goes. Far better
than anything I've ever seen or heard of actually, because you can
visualize MIDI any way you want, which has waaay more potential than
visualizing
On Wed, May 12, 2004 at 03:03:27PM +0200, Frank Barknecht wrote:
Jens M Andreasen hat gesagt: // Jens M Andreasen wrote:
To reiterate the question: SuSE 9.0 or Mandrake 10.0?
I've been using a standard SuSE 9.0 (2.4) for about six months now,
and it performs very well for audio work.
Like I mentioned earlier, having jack used for every connection in, say,
a modular synth, would make your jack patching too complicated to be
useful. This most definatley would not be easier to use.
Plugins in an app and connecting different apps is just different,
period. I can't think of
You seem to be really attached to this idea.. I guess what I don't
understand is.. why? What, exactly, is the point/benefit?
It's really not that I think anyone should follow my suggestions, I'm not an
experienced enough programmer. The reason I piped up again was because I
think it is very
Hoping some one can throw some light on this for me, I've been dutifully
doing my best to research it but am overwhelmed with all the info, much of
which looks like it might be out of date.
The object is to port my csound sequencer to C and run it on linux. It will
be a real time multi threaded
This is what AMS, SSM, gAlan, PD etc let you do right now - MIDI is
converted
to a 'voltage' signal (by various means) and then routed to plugins in the
graph. Ditto JACK - you can connect a JACK port to anything you like in
these
apps.
I don't know near enough to say it should be Jack
Having every single connection, useful or not, done through jack would
make your jack patch bay SO incredibly complicated and crammed full of
garbage as to be totally useful.
But you're mashing the ideas of modules in an app and connecting
multiple apps together - different problems. A jack
I think the way to make an inter app modular really useful and new would be
to use Jack for *ALL* signal passing including control signals as CV
emulations by passing a DC signal through Jack ( as say an equivalent of a
Csound krate signal or a hardware modular control volt signal.) If the
modular
This is the best: http://www.ucapps.de
If you want other links just ask on his forum.
Iain
- Original Message -
From: Adam King [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 7:51 PM
Subject: [linux-audio-dev] Introduction to building MIDI controllers?
Found some good reading material on real time programming and now have a
couple more questions if anyone can share:
- what are the pros and cons for a sequencer engine of using pthreads in one
address space vs seperate processes spawned by one application? Anyone know
what the various linux real
softwerk is totally designed like this. you get it for free by using
an MVC programming design. (almost) nothing that happens in the GUI
can stall the engine. softwerk itself likes to use the RTC for timing
purposes. running the engine thread SCHED_FIFO is also a key
ingredient of this.
The previously mentioned stuff at Ucapps is pretty rad. I'd even say it's
better than any commercial options. After all, find me a commercial midi box
with a bootstrap loader that lets me change the firmware over the serial
port . . . A friend of mine, DJ Lace, ( www.vutag.com has his open source
Hi everyone, I've been working for the last couple of years on a live improv
sequencing system in Csound, and I would like to start porting parts of it
to C so as to allow it to run faster as opcodes within csound and as stand
alones. I need to learn how to do multi-threading with priority
Sorry I guess I didn't make myself very clear there. I don't mean that I
wan't to make an audio ap and would do the audio stuff myself, I'd
definitely use Jack for that. I'm making a step sequencer to drive midi gear
and csound synths. So the timing I'm concerned about is the engine of the
as a block of solid colour in most
viewers.
I am interested to hear any and all feedback of course.
Thanks,
Iain Duncan
36 matches
Mail list logo
