Analogue-sequencer

Chiel,

> the way it
> used to work was that if i just turned the rep*N value up to max, i
> could vary the number of repeats with the note-length. so if the
> length value was 12 i'd get no repeats, if the length was 6 the
> number of evenly spaced repeats would be 2, if the length was 3 i'd
> get 4 evenly spaced repeats, a length of 4 would make it a triplet
> repeat, 2 made 6 repeats etc., and i could get nice sort of up-beat
> things before the following note with length values above 6. the new
> version still interacts with the length parameter, but the smallest
> number of repeats i can get, with note-length set to 12 (max) appears
> to be something like 4 or 5, in a pattern with tbase 4. the extended
> value is cool, being able to get more than 8 repeats, is cool, but
> i'd really like to see the old way of interacting with the length
> value back..

Aha, the non-16 tbase is the key here...
The previous repeat notes were triggered when the gate length counter
reached zero - this would trigger a repeat if any were set.
Now there is a separate 'repeat time' counter that counts the ticks until
the repeat note should trigger. This counter is set to a division of tbase
to allow equally divided repeat notes.
To recreate the rep*N event, I just set the repeat time to the note length -
but this is done before the length is scaled by tbase. Did you find the
behaviour was the same as before at tbase 16 ?
I'll need to add a scaling of length by tbase as it is written to the repeat
time...

> btw i had some weird stuff going on during sysex dumps back to the
> P3's after doing the bootloader update; during the upload of the
> latest FW after the bootloader update the display kept flickering BAD
> DATA through the usual 'send more data' routine. i did the whole
> thing twice on the first machine with identical results, then once on
> the other, again with the same result, so i figured it'd be ok. i got
> the same kind of flickering BAD BLOCK messages through the sysx-
> memory dumps back to the P3's on both occasions too. but it all seems
> to be working fine so i guess it's allright.

That's more likely to be a midi lead or opto problem.
The new bootloader code is identical - it's just re-assembled to run at a
higher memory location.

Cheers,
Colin f



________________________________________________
Message sent using UebiMiau 2.7.2