Re: [linux-audio-dev] News about sequencers (not my own though!)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: Paul Winkler (slinkp23_AT_yahoo.com)
Date: su tammi  23 2000 - 18:44:57 EST


David Slomin wrote:
>
> Paul Winkler wrote:
> >
> > Very interesting idea. Though from what you've written, I'm not sure
> > what I'd gain by keeping pysco in the equation at that point, since
> > I'm not sure what pysco can do that PEGS can't. (In fact following
> > this thread has occasionally made me wonder just how much of my time
> > I'm wasting. :) )
>
> Ah, but you already have something usable, whereas I have some
> foundation code and a lot of design ideas. One in the hand worth
> two in the bush and all that!

You haven't looked at pysco very closely, have you? :)
I have something "usable" for generating csound scores, but I have
already found it nearly impossible to keep track of what I'm doing
since I don't yet have a way to provide reference times that other
things can sync to (otherwise known as section boundaries). Fixing
this in the current design seems like a hack; a re-design that
simultaneously solves other big problems seems like a much better
idea. So I'm really not very far along.
 
> > PEGS, in turn, would then
> > > be able to sequence algorithmically generated phrases, with each
> > > such phrase mapping to one PEGS event. Here, as with audio clip
> > > sequencing, the mixdown for output would be rather critical.
> >
> > Interesting...
> > How do you see this working? Would each PEGS event somehow request
> > pysco to generate this algorithmic phrase? How would communication
> > be done? Pipes?
>
> I don't understand the full workings of Pysco yet, so maybe I'm
> off track, but here's what I was thinking: For an algorithmic
> composition system, I would envision a set of functions that
> generate phrases according to a few parameters such as starting
> time and current chord.

This kind of thing is pretty easy to do in python or any interpreted
language... pysco or no. Hopefully, my nested event design will make
it even easier. And I do hope to provide a bunch of useful tools
such as interval maps for various modes, functions to translate
between various pitch notations, and handy event subclasses such as
chords, "heaps" (like in CM), etc.

> The functions would then be invoked
> with different combinations of arguments to produce an output
> file (or realtime stream). The function definition stage would
> be handled by Pysco as it always is, but the invocation stage
> would be controlled by PEGS events.
 
> If you wanted a simple, non-realtime way of communicating between
> the two programs, assume that Pysco works like Csound where the
> function definitions are placed in an orchestra file and the
> invocations are placed in a score file. PEGS would generate the
> score file and exec Pyscore when a "play" button was pressed.
> It's fairly easy to get fancier with pipes, sockets, or shared
> memory if you want a faster response when pressing play.

That should work. Keep in mind that pysco is, and is likely to
remain, relatively slow.

I was wondering, what about the other way? What if we provide pysco
with an output protocol for PEGS events? Can you think of uses for
that?
 
> The whole issue of nested events is trickier, since in this simple
> version PEGS knows about Pysco events but not the other way around.

hmmm... you got me there.

 
> Just musing... there's a lot of potential here
> Div.

................ 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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST