Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: Paul Winkler (slinkp23_AT_yahoo.com)
Date: ke tammi 19 2000 - 02:40:18 EST
This is a pretty interesting thread! Very relevant to ideas I'm
playing with for pysco...
> David Olofson 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?)
> > My idea: Clips inside clips. (Allow any number of levels if you dare,
> > but it might be too much for some users to sort out... ;-)
>
> I had to think long and hard about this one and how it maps into
> the PEGS paradigm. I think the most straightforward (?) way to do
> it would be to define an "event list pointer" event type (event type
> is just another user-provided property). You would then provide a
> pen callback (which is used when you click on the event in the
> display window) that opens a new display window with the event list
> it points to. Because it's a pointer, you then get "clip linking"
> for free (although you have to provide explicit create, delete, and
> duplicate commands somewhere). Loading and saving would be tricky,
> since SMF (MIDI files) doesn't support this, but PEGS allows you to
> plug in your own file formats if you want (yes, every single thing
> in the damn program is a callback). How's that sound?
Pretty cool. I've been thinking about graphic interfaces to pysco,
and more to the point I'm doing some testing of nested events, and I
think I've hit on some ideas that will work well for me.
My idea is to throw away any imposed idea of "tracks" and "sections"
entirely, since really these are just different ways of looking at
and working with nested events. A track is a sequence of events that
can happen parallel to other sequences of events. A section is a
sequence of events that may be broken down into tracks, or not. It's
up to the user to think of the way to best organize his/her musical
data. Before I thought of doing it this way, I was annoyed that I
couldn't think of a way that a pysco "chunk" could contain
information in more than one "track" (and in fact, I was using
"track" in kind of an arbitrary fashion, since all I used tracks for
was to make it hopefully a little easier to manage timing of events
in a non-GUI environment).
Another advantage of my approach is that an "event" can now be
literally anything that defines an "output" method. (I might replace
this with a "rtplay" method to play in realtime, and a distinct
"render" method to generate file output.)
Consider this code (it's python, but even if you don't know python
it shouldn't be too hard to read). It's not especially brilliant,
but it only took me a few minutes.
class PyscoEvent:
"""Takes two arguments: a start time, and a list of
sub-events."""
def __init__(self, at=0, value=[]):
self.at = at
self.items = value
def output(self, at=0):
# Change self.at ONLY if given as an arg to self.output().
# This allows us to both provide
# a default time at __init__ and change it at output() time.
try: self.at
except NameError: self.at = at
# Now play the event. In this sketchy version, all I'm
# doing is printing the event's data and the updated
# value of self.at...
for s in self.items:
s.old_at = s.at # Need to restore s.at in case this
event
# gets called again! Otherwise s.at keeps growing...
# Actually, I think output shouldn't use s.at directly!
s.at = s.at + self.at
print ";;; event at", s.at
s.output()
s.at = s.old_at
class Note(PyscoEvent):
""" A single event. """
# Inherit the init method. But redefine output().
def output(self, at=0):
try: self.at
except NameError: self.at = at
for p in self.items:
print `p`,
print
# tests
fred = Note(at=0.01, value=("this is fred", 1, 0, 3, 4.05))
billy = PyscoEvent(0.1, (fred,
fred,
Note(4, (";; NESTED ANONYMOUS NOTE!!",)),
PyscoEvent(5, (fred,
Note(0, (";;NESTED ANONYMOUS
EVENT!!",)),
)
)
)
)
bob = PyscoEvent(at=0, value=
(billy,
fred,
Note(10.0, (";; anonymous comment!",)),
Note(25, (";; ANONYMOUS NOTES WORK!!",))
)
)
bob.output() # This recursively outputs everything...
------ end of sample code. -----------------
Here's the output of running that:
;;; event at 0.1
;;; event at 0.11
'this is fred' 1 0 3 4.05
;;; event at 0.11
'this is fred' 1 0 3 4.05
;;; event at 4.1
';; NESTED ANONYMOUS NOTE!!'
;;; event at 5.1
;;; event at 5.11
'this is fred' 1 0 3 4.05
;;; event at 5.1
';;NESTED ANONYMOUS EVENT!!'
;;; event at 0.01
'this is fred' 1 0 3 4.05
;;; event at 10.0
';; anonymous comment!'
;;; event at 25
';; ANONYMOUS NOTES WORK!!'
So, I'm pretty optimistic about eventually making pysco into
something that I can easily make really interesting music with, both
by writing scripts AND by developing simple but interesting
interactive GUIs.
I'm also not very optimistic about it handling heavy-duty realtime
work. Just running some extremely simple python event timing tests
took about 10 to 20% of my CPU time on a 333 MHz celeron-based box.
Events were anywhere from 2 to 10 milliseconds behind when I asked
them to be, with occasionally REALLY late notes, like 300 ms or so.
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 ...
................ 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