electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » DIY Hardware and Software » Supercollider
Thinking about structure in a through-composed piece
Post new topic   Reply to topic Moderators: v-un-v
Page 1 of 1 [7 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Tue May 20, 2008 7:36 pm    Post subject: Thinking about structure in a through-composed piece Reply with quote  Mark this post and the followings unread

Whew! Spent most of the weekend debugging some really knotty code, but finally got it working well enough and discovered the constraints to make the code continue to work (which is just as important).

It's all about flow of control for a piece for violin and computer where some (perhaps most) sections will be rhythmic with a lot of meter changes. So here's what I had on my mind --

- the performer should be able to jump ahead and start the computer part at every rehearsal marking;

- the computer needs to know when one section ends (crosses over to the next rehearsal mark) and automatically update;

- sections should load their resources incrementally, which I ended up implementing through forwarding of notifications;

- the "conductor" process, which performs meter changes and provides other high-level information to sound-making processes, has to run ahead of everything else so that its information is ready before other processes use that information;

- that means the "section" object must start just ahead of the beat, in time with the conductor, and other processes have to schedule themselves properly relative to the meter -- this called for "command" objects that describe the action to be performed along with all the parameters that are needed (such as a Quant-style scheduling specification) -- commands also know their status and can notify the caller when they complete;

- one section yields control to another when all of its processes run out of material -- but of course some processes need to run continuously across section boundaries. That's where it gets really confusing, with some process-trigger commands that can synchronize (which will hold the end of the section until they finish) and others that don't have to synchronize -- in which case they get saved at the end of the section and passed on into the next section.

- And of course all of this has to be run by a GUI that a non-technical person could use.

As long as I make sure that only the conductor can synchronize and that every other process either plays through or explicitly stops itself at the right time, I think I can build a fairly long piece this way. It remains to be seen whether the structure will survive past this composition -- if anything, it's too complicated for its own good -- but maybe it just needs some re-factoring later on.

Just trying to start some conversation -- I know this is sketchy on the details. What's interesting to you in any of this?

hjh

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Blue Hell
Site Admin


Joined: Apr 03, 2004
Posts: 23286
Location: The Netherlands, Enschede
Audio files: 257
G2 patch files: 320

PostPosted: Wed May 21, 2008 9:54 am    Post subject: Re: Thinking about structure in a through-composed piece Reply with quote  Mark this post and the followings unread

dewdrop_world wrote:
What's interesting to you in any of this?


It reminds me on my ever ongoing struggle with test software for testing hardware Laughing

A test can be in certain states and in order to use the software for hardware debugging as well it's nice to be able to go forwards and backwards through those states. Some of the states can be associated with lengthy processes, like having a communications session with the device under test ... it's pretty hard each time to get stuff like this working good ... or even acceptable ... over the years I've built a couple of frameworks for this and I'm not really happy with any of 'm.

_________________
Jan
also .. could someone please turn down the thermostat a bit.
Posted Image, might have been reduced in size. Click Image to view fullscreen.
Back to top
View user's profile Send private message Visit poster's website
Ludvig



Joined: Jul 25, 2005
Posts: 26
Location: Stockholm - Sweden

PostPosted: Thu May 22, 2008 8:54 am    Post subject: Reply with quote  Mark this post and the followings unread

This all sound really interesting and I have some questions.

Quote:
- the computer needs to know when one section ends (crosses over to the next rehearsal mark) and automatically update;


What would the computer update here? Information to the violin player?
Are the sections fixed in lenght? Do you mean that there is some analysis or score-following taking place that tells 'the computer' where it is?

The conductor conducts the section objects ( that play one after another? ) that controlls command objects that control sound synthesis. Is that correct?

Quote:
- one section yields control to another when all of its processes run out of material -- but of course some processes need to run continuously across section boundaries. That's where it gets really confusing, with some process-trigger commands that can synchronize (which will hold the end of the section until they finish) and others that don't have to synchronize -- in which case they get saved at the end of the section and passed on into the next section.


I read this part a few times and I do not really get it ( English isn't my native language so that is probably one of the reasons I didn't ).
Do you mean that some command objects gets passed along from one section object to the next?

Could you maybe describe the musical idea ? I would very much like to learn more about how you achieve this fine tuned system of control and it might be easier to understand the implementation if I knew what you were trying to acheave musically.

At least you seem to have a very impressive neatly organized object oriented structure in your mind so congrats, I will probably be great. Smile
Back to top
View user's profile Send private message
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Fri May 23, 2008 12:37 pm    Post subject: Reply with quote  Mark this post and the followings unread

Ludvig wrote:
What would the computer update here? Information to the violin player?


The GUI displays the current section.

A lot of the motivation is to avoid repeated code. I could possibly handle it by having section A contain information for ABCDEF... etc., section B contain BCDEF... and so on, but that's a lot of wasted effort.

Ludvig wrote:
Are the sections fixed in lenght? Do you mean that there is some analysis or score-following taking place that tells 'the computer' where it is?


They can be fixed in length or you can set up some sort of user trigger to move on to the next thing. The trigger could be MIDI, keyboard or a signal from a machine-listening UGen. (I probably won't do much with machine listening in this piece, but the structure exists to support it.)

Most section durations in this piece will be hard-coded to match the score. I expect some partially aleatoric sections that will require a trigger to move forward.

Ludvig wrote:
Do you mean that some command objects gets passed along from one section object to the next?


Yes - one problem being that when you hit "stop" in the interface, that message has to reach all of the objects that are currently playing.

The scenario I was testing is a breakbeat process that plays continuously for several bars, and there's a rehearsal marking in the middle. Rehearsal marking = section, so the beat has to play through without interruption and continue into the next section. The way that this is handled is like this:

- section A comes to an end - it sees that there are active commands still running, so it saves them in a collection (IdentitySet) and sends the \done notification to the parent, passing the Set up the chain.

- section B takes over and receives the Set, which it uses to initialize its own activeCmds set

The command from section A (transferred into B) remains active only as long as a whole thing is playing. If it's stopped (manually or automatically), the command is removed and section B forgets about it.

There's a lot going on in the system and I can't put all the details into one posting, so keep asking questions Smile

James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Sat May 24, 2008 7:51 pm    Post subject: Reply with quote  Mark this post and the followings unread

Here's a short excerpt. The breakbeat is chugging along, along with kick drum and snare accents. Today I also added a prototype of a bassline -- I'm not quite happy with it but I wanted to be sure I could generate the material and have the harmonic content change at the right times in the score.

Forgive the rough mix -- this is at a really early stage of production.

And, the code as it stands now (excluding the process details, since this thread is about the higher-level structure) -- it uses other code that exists locally on my machine, which I'm not ready to release yet (sorry). But at least it might make it more concrete what I mean by "sections" and "commands."

James

Code:
// must load proto-cmds, core processes and transports, before doing this
(
BP.all.free;

~sections = [PR(\tlSection).copy.putAll((
   startBeatsPerBar: 4,
   initProcesses: {
      BP(\cond).free;
      PR(\conductor).chuck(BP(\cond), nil, (
         meter: Pseq([4, 3, 15/4, 4, 3], 1),
         numBars: Pseq(#[1, 1, 1, 3, 1], 1),
         barDiv: Pseq([
            (bass: #[0, 0.75], snr: #[1.5], avail: (8..15)),
            (bass: #[0, 1.5], snr: #[0.75, 2.25], avail: \getRests),
            (bass: #[0, 1.25, 2.5], snr: #[0.75, 2, 3.25], avail: \getRests),
            (bass: #[0, 0.5, 1.5], snr: #[1, 2, 2.5], avail: (12..15)),
            (bass: #[0, 3.25], snr: #[3, 3.75], avail: (0..15)),
            (bass: #[0], snr: #[0.5], avail: (4..15)),
            (bass: #[1.5, 2.0, 2.25, 2.75], snr: #[2.5], avail: (0..5))
         ], 1)
      ));

      // more processes get initialized here (omitted)

   },
   seqPattern: {
      Pbind(
         \sequence, Pseq([
            [funcCmd: (func: {
               BP(#[brk, k, snr, b2]).do(_.cond_(\cond))
            }),
            funcCmd: (func: { Library.put(\bassMapping, #[31, 37, 39, 43, 45].mapMode(\gmin)) }),
            bpCmd: (name: #[brk, k , snr, b2], quant: #[1, 0], shouldSync: false),
            bpCmd: (name: #[cond], quant: #[1, 0]),
            23.75, notifyCmd: (notification: \initNext, passthru: true)]
         ], 1),
         \dur, \sync
      )
   },
   name: "break"
)),
PR(\tlSection).copy.putAll((
   name: "break2",
   initProcesses: {
      PR(\conductor).chuck(BP(\cond2), nil, (
         meter: Pseq([4, 3, 1.25, 5, 1.25, 3, 1.25, 4, 2, 4, 3, 4, 3, 1.5, 3], 1),
         numBars: Pseq(#[1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 3, 2, 1, 2], 1),
         barDiv: Pseq([
            (bass: #[0, 2.5], snr: #[1, 3], avail: \getRests),
            (bass: #[0, 2.5], snr: #[1], avail: \getRests),
            (snr: #[0], avail: \getRests),
            (bass: #[0, 2.5, 4], snr: #[1, 3], avail: \getRests),
            (snr: #[0], avail: \getRests),
            (bass: #[0, 2.5], snr: #[1], avail: \getRests),
            (snr: #[0], avail: \getRests),
            (bass: #[0, 2.5], snr: #[1, 3.5], avail: \getRests),
            (bass: #[0], snr: #[0.5, 1.5], avail: \getRests),
            (bass: #[0], avail: (2..15)),
            (snr: #[1, 1.75, 2.25], avail: #[0, 1, 2, 3, 10, 11]),
            (bass: #[0, 0.75], snr: #[1.5], avail: (8..11)),
            (bass: #[0, 2.5], snr: #[0.75, 1.5, 3, 3.25], avail: \getRests),
            (bass: #[1, 2.75], snr: #[0, 0.5, 1.25, 2, 2.25, 3], avail: \getRests),
            (bass: #[0, 0.75, 1.5, 3], snr: #[1, 2.5, 3.25], avail: \getRests),
            (snr: #[0, 0.75, 1.5, 2.25], avail: \getRests),
            (snr: #[0, 0.75, 1.5, 2.25], avail: \getRests),
            (snr: #[0, 0.75], avail: \getRests)
         ], 1)
      ));
      BP(\cond2).leadTime = 0.2;
   },
   seqPattern: {
      Pbind(
         \sequence, Pseq([
            [funcCmd: (func: {
               BP(#[brk, k , snr, b2]).do({ |bp| bp.cond_(\cond2) });
            }),
               // change pitch content of bass at start of section
            funcCmd: (func: { Library.put(\bassMapping, #[31, 38, 41].mapMode(\gmin)) }),
            bpCmd: (name: #[brk, k , snr, b2], quant: #[1, 0], shouldSync: true),
            bpCmd: (name: #[cond2], quant: #[1, 0], stopAll: true),
            4+3+5+3+4+2+(3*1.25),
               // change content again
            funcCmd: (func: { Library.put(\bassMapping, #[31, 37, 43, 45].mapMode(\gmin)) }),
            22,
            funcCmd: (func: { Library.put(\bassMapping, #[38, 43, 45, 48].mapMode(\gmin)) })
            ]
         ], 1),
         \dur, \sync
      )
   }
))
];
)

~seq = PR(\sectionSequencer).copy.putAll((
   sections: ~sections
));

PR(\transports).copy.model_(~seq) => BP(\transports);



section-gui.jpg
 Description:
GUI for the performer
 Filesize:  26.96 KB
 Viewed:  8270 Time(s)

section-gui.jpg



section-demo.mp3
 Description:
Rough demo of section transition.

Download
 Filename:  section-demo.mp3
 Filesize:  704.75 KB
 Downloaded:  886 Time(s)


_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Ludvig



Joined: Jul 25, 2005
Posts: 26
Location: Stockholm - Sweden

PostPosted: Sun May 25, 2008 12:49 am    Post subject: Reply with quote  Mark this post and the followings unread

Wow it's really nice of you to share this so we all can learn from it. I'll probably be back with more questions shortly.
Back to top
View user's profile Send private message
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Tue Jun 10, 2008 7:54 pm    Post subject: Reply with quote  Mark this post and the followings unread

Thread seems to have died...? Anyway, still working on it and it's still going well. The other day I was able to add a companion command to "bpCmd" which, instead of turning the process loose to play on its own time, triggers just one event from the process and lets that event stay active until the next command. That was to handle a section with a flowing melody in the violin where the chord changes should happen based on foot switch triggers from the player instead of being pre-timed -- why not allow some expressive rubato?

So far it's proving to be extensible in whatever direction I need -- I'm happy!

James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Display posts from previous:   
Post new topic   Reply to topic Moderators: v-un-v
Page 1 of 1 [7 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » Supercollider
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
e-m mkii

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use