Critique a beginner's code!

[Larry Troxler]

>
>Q. syntax is a bit awkward - why can't symbolic values be directly used in
>   algo inits? 
>A. because there is no way for the algorithm expander to know how to 
>   convert the data.  Hence, it's always unconverted ("raw").

Yes, on giving it a second's thought this is obvious - algorithm parameters
aren't "typed".

>Q. would be nicer to us symbolic intervals here - how do i do that?
>A. symbolic intervals make only sense in a chromatic scale.  intervals
>   etc, however, operates on any scale.

Yes, I think I need to investigate how scales work. I assume you can define
as many scales as you need and use them locally on specific streams. I'll
look into it. Sounds like a better way of working, anyway.


>Q. there's got to be a better way than the mix/max bit. What I really want is
>   to choose a new subseq at a rythmic rate of E*7*2*2 = once every 'root 
>   cycle (see 'root stream below). How should I do that?
>A. use the for option as shown below
>|#
>
>;;; The "Org400" part
>
>(defun do-Org400 (chan)
>  (algorithm Org400 pnote (end (- *opus-len* 1) patch 'Org400 channel chan
>			       amplitude (amplitude 'mf) duration (rhythm '32))
>    (setf note (item (intervals 7 2 0 linked-to 'root)))
>    ;; variations on a 7/8 rhythm.
>    (setf rhythm (item (rhythms e.
>				(rhythms (rhythms e. e e for 12)
>					 (rhythms e  e. e for 12)
>					 (rhythms e e e. for 12)
>					 in random for 1)
>				e e)))))
>

Nope, sorry. This doesn't give the same output as my original example. The
intent was that the rhythm cycle always covered a 7/8 measure (the three
randomly choosen subsequences are of the same length). On listening to your
revision, I hear something different.

>Q. Eventually it would be nice to have a channel allocate/free setup. Any
>   prior art in this area? 
>A. I don't understand the question.

I meant that instead of needing to specify specific MIDI channels, that
there could be a system where an algorithm "allocates" a free channel, and
"frees" it when it is done with it. Basically, I have a synth which is
pretty good about dynamic voice allocation and patch changes (Korg
Wavestation), and hence it would be nice to have some sort of MIDI
housekeeping layer which handles the patch changes (above) and assigning
parts to an unused channel on a dynamic basis.


>Q. One problem with this merge is that the 'root item selection seems to
>   happen *after* the item selections of the two threads, making the change
>   of root hapen after the beat instead of on it. What determines the order 
>   of evaluation and how should I fix this problem?
>A. your rhythm stream in Org400 starts with an initial offset of "e.", and 
>   then intersperses two more "e"'s after each inner cycle.  I like it
>   though.  This example shows you that it works:
>

I haven't yet ran your example, but on further investigation, the problem
isn't with the Org400, but with the Vulcan-Harp algo. (see above wrt. your
Org400 revision resulting in different output). 

The strange problem I am having turns out to be only with the "Vulcan-harp"
part. The Org400 part does in fact switch transpositions on the 7/8 meter
boundaries. But the Vulcan-Harp is one note late in switching. I tried a few
modifications to no avail. I supposed it must be some sort of rhythm
round-off problem, where the Vulcan downbeat actually is schedulled slightly
before the "root" change. So as an experiment I tried delaying the Vulcan
algorithm's  "start" parameter to 0.01 to ensure that the Vulcan part was
always scheduled slightly after the corresponding beats of 'root. 
But this didn't work!

I'm completely stumped on this one.

To make things even more confusing, when I play your revision, the Vulcan
part works correctly! So what's different??

Larry