IDEA: EXPLAIN HIERARCHICAL SYNTH


To: technocore@goto10.org
Subject: [technocore] piksel thoughts...
In-Reply-To: <4719FDB3.1090008@goto10.org>
References: <4719FDB3.1090008@goto10.org>
X-Mailer: VM 7.19 under Emacs 22.1.1
--text follows this line--

bonjour
marloes writes:
 > some thoughts on piksel and also on general development:
 > 
 > if we want to play at piksel without computers, we need to use sheepsint 
 > with batteries, Tom, did you test this yet? It is not essential (we 
 > could hide the computers haha) but it would be necessary for the meshy 
 > project too.

The synths work with batteries, tested in huddersfield during the
workshop. The only thing i need to do is to figure out where to put a
resistor so it won't start in debug mode. I'll test that today.

 > 
 > if we want to look really cool, we need casing for the sheepsint :)
 > I 

Yes

 > would like to dedicate some time to this. I will solder some extra 
 > boards with the reset and other buttons detached from the board, so we 
 > can put them into ultra cool cases. I think I have all I need to solder 
 > 2 more boards. But if I miss something I'll post here.
 > 

ok. making a case should be straightforward. i dont know if you have
the plastic 2xAAA batter holder. that's the only thing that needs to
go in there.

 > if we want to make cool music, we need some basic tests for:
 > - portamento
 > - envelope-like behavior for beats etc.
 > - vibrato would kick ass :) but not sure how realistic that is...
 > - arpeggiator for aymeric
 > 
 > and of course we still need the ultra smooth system that will put all of 
 > those features into one easy to control instrument :D
 > 
 > Tom: any hints/tips you can give us to do some experimenting along these 
 > lines? We need to practice our purrr anyways and frere jaques is 
 > starting to loose it's charm.
 > 

* modification to period

elaborate frequency modulation stuff needs some 16bit math. i think
it's best i just write those, and give you the interface later, but
the idea is:

	- load the 16bit period on the stack
	- perform some 16bit math
	- store the 16bit period

you can start with loading/storing only the 8 bit periods.

* envelopes

i don't know what you mean by this, but the output is 1 bit, there's
not much room for envelopes.. it's on or off. so need to resort to
different tricks: the only thing you can play with is how long things
last, and when they happen.

* recursive time scale

what you want sometimes is to modify different parameters through
time. this can be a pain without multitasking, but is the way it has
to work for now. try to think of a piece of music as a hierarchy of
time scales. let's give them a name:

      - bar:     syncs to whole notes
      - note:    syncs to 1/16 bites
      - control: syncs to a 244 Hz signal

you can make your own by defining macros using the 'sync-tick'
word. the idea is that you can just call words from a FINE time scale
from the COARSE time scale. to make this easy, each word that does
something should have the structure:

	: tingeling   SYNC CHANGE-PARAM ;

now for example a 4 note beat is:

        : beat        bar beat0 beat1 beat0 beat1 ;

then on the beat time scale OOPS!

  

think of a word which produces a 


* transients

the way to go is the following: if you look at a note as a time slice:

nnnnnnnnnn

what you can do is to modify the synt algorithm in the beginning of
the note, something like:

ttnnnnnnnn

where you could temporarily switch to a noise algorithm during the 't'
phase, and switch back to periodic sounds in the rest. there are 2
things to keep in mind:

  - synchronization
 
     the idea is to recursively divide up your time: the toplevel
     should sync to beat frequency, for example.

    


  - save/restore

     the simplest way is to use the data stack, and/or the aux stack
     (>x x>) to save synth config before you reconfigure the algo







marloes writes:
 > some thoughts on piksel and also on general development:
 > 
 > if we want to play at piksel without computers, we need to use sheepsint 
 > with batteries, Tom, did you test this yet? It is not essential (we 
 > could hide the computers haha) but it would be necessary for the meshy 
 > project too.
 > 

the synth works fine with batteries. the only thing i need to still
check is if it can detect the absence of a programming cable. i'll do
that today.

 > if we want to look really cool, we need casing for the sheepsint :) I 
 > would like to dedicate some time to this. I will solder some extra 
 > boards with the reset and other buttons detached from the board, so we 
 > can put them into ultra cool cases. I think I have all I need to solder 
 > 2 more boards. But if I miss something I'll post here.
 > 

good idea.


 > if we want to make cool music, we need some basic tests for:
 > - portamento
 > - envelope-like behavior for beats etc.
 > - vibrato would kick ass :) but not sure how realistic that is...
 > - arpeggiator for aymeric
 > 
 > and of course we still need the ultra smooth system that will put all of 
 > those features into one easy to control instrument :D
 > 
 > Tom: any hints/tips you can give us to do some experimenting along these 
 > lines? We need to practice our purrr anyways and frere jaques is 
 > starting to loose it's charm.
 > 

i'll write a little tutorial: i was replying to this email but found a
big conceptual error in my thinking about sync.

but, some basic tips:

  * call some words that sync on the 'wait-control' in a loop from
    words that sync on 'wait-note'
 
    the basic idea is that you divide up your time recursively: each
    bar is made of notes, each note is made of control modifications.

  * transients

    something that works pretty well is transients: at the beginning
    of a note do:
	- save synth parameters on the control stack
	- change parameters, loop on 'wait-control'
        - restore parameters
 
    this gives a note which has some 'stuff' at the
    beginning. i.e. switch to noise or higher frequency during a small
    part of the note.

  * use state variables that store current functionality, and execute
    them using the 'route' command. what i mean with this is that you
    can 'pretend' you have different tasks running by using words
    like:

       : hihat  #x0F and route 
            x ;   ;   ;    ;
            x ;   ; x ;    ;
            x ;   ;   ;    ;
            x ; x ;   ; x  ;

    where 'x' does some parameter changes, then store the current
    state in a variable:

       variable hihat-state

    and execute it some place using the code sequence 

       hihat-state @ hihat

    you need to manually increment the state vector using something
    like:

       hihat-state 1+!

    see what this looks like? the variable 'hihat-state' is actually
    an INSTRUCTION POINTER for the PROGRAM in hihat. what we just did
    is to make a VIRTUAL MACHINE for pattern sequencing.

    cream on top: put the ugly stuff in a macro:

       macro
       : pattern #x0F and route ;
       forth

       : hihat  pattern
            x ;   ;   ;    ;
            x ;   ; x ;    ;
            x ;   ;   ;    ;
            x ; x ;   ; x  ;

     
i hope this helps until i have more working examples + docs.  i
appreciate that it is very difficult to build up a general feeling
about how to do things, since it's a certian way of thinking. and i
find it terribly difficult to dump this kind of knowledge on paper in
a serial form, but that process in itself is rather interesting :)