Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: Paul Winkler (slinkp23_AT_yahoo.com)
Date: pe tammi 21 2000 - 03:46:11 EST
David Olofson wrote:
>
> On Wed, 19 Jan 2000, Paul Winkler wrote:
> > > > Anyway, I think the most interesting of one of those old ideas was to
> > > > remove the track concept, and use the Y axis in the arrange view only
> > > > for layout.
> >
> > Sorry, I haven't used any of these sequencers in a loooong time.
> > What exactly is the "arrange view"? (Screenshot anyone?)
>
> Here's one from CW9:
> http://www.cakewalk.com/Products/PA/TrackviewB.jpg
>
> (Yes, the GUI is *very* slow with that configuration...)
>
> Works pretty much like a piano roll editor, where the Y axis
> addresses tracks, and the "notes" contain MIDI events or audio clips.
>
> > But then, this is on a 2.0 kernel without all the fancy low-latency
> > stuff installed yet. One of these days I really need to upgrade.
> > But then again, I don't know if python is currently able to take
> > advantage of realtime priority anyway! I'll look that up before I
> > order another linux CD ...
>
> Interpreted languages (and actually any language that uses garbage
> collection and similar techniques) have inherent problems with real
> time - you never know when the garbage collector steps in for some
> cleaning! I some implementations, you can force a garbage collection
> when it won't disturb the real time processing, but you may not be
> able to guarantee that it won't happen an extra time in the middle of
> the real time code...
I don't know what, if anything, I can do about this... except hope
it's not too bad. :) People on comp.lang.python may be able to
help... or not.
> Further, speed might be a serious problem.
Well, I knew that when I started. I wouldn't be fiddling with
realtime output at all if it wasn't already almost good enough for
me to have a little fun with. To be honest I expect pysco to shine
in non-realtime applications. In that mode I have yet to do anything
that feels slow (but I haven't really tried yet...)
> Even if it could be acceptable to eat 80% of the CPU time,
I haven't really done any stress-testing yet, but I think that
figure is high for even a low-end modern machine like mine (333 MHz
celeron). Anyway, if I get into really heavy-duty algorithmic stuff
with tons and tons of events, I'll certainly not be trying to drive
a softsynth with pysco at that point... I'll just overload my midi
port instead. :) I'm not expecting miracles from pysco in realtime;
I'd have to spend a few years learning serious compiled languages
instead, and that's just not my interest at this point. I'd just
like to be able to make fun little pseudo-drum-machine things with
weird interfaces, and that seems feasible even with my cheap
hardware.
> you have to
> buffer the results (and output them using some streamlined function,
> preferably in native code),
newbie question: what is "native code" anyway?
> to get rid of the jitter that grows with
> execution time.
Does this mean that timing tends to get increasingly erratic as the
run goes on?
................ paul winkler ..................
slinkP arts: music, sound, illustration, design, etc.
A member of ARMS -----> http://www.reacharms.com
or http://www.mp3.com/arms or http://www.amp3.net/arms
personal page ----> http://www.ulster.net/~abigoo
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST
