Analogue-sequencer

Folks,

This beta version adds:
 * active track part copy - copies only playlists on unmuted tracks
 * quick mute access - in edit mode, hold FUNC and press PLAY/EDIT.
    while FUNC is held, step keys act as track mutes

Works OK here, let me know of any bugs. 
I'll need to update the manual sometime...

Cheers,
Colin f

> This beta version adds:
>  * active track part copy - copies only playlists on unmuted tracks
>  * quick mute access - in edit mode, hold FUNC and press PLAY/EDIT.
>     while FUNC is held, step keys act as track mutes
> 
> Works OK here, let me know of any bugs. 
> I'll need to update the manual sometime...

..nice one Colin, very nice one this. both functions work fine here..
the quick mute access is great! works really intuitively, and is 
pretty easy to access from playlist-edit as well. as i suspected this 
one is a lovely live tool (been playing around with it until deep in 
the night...again).
the active part copy is also great; i also found out that you can use 
the 'mute hold' (better name for it i think) in combination with 
the 'part copy - all' function. and this can be used in combination 
with the 'func+part change' function so mute changes aren't saved in 
the source part when switching...sweet fun! 
this has made me want another possibility as well though; in addition 
to the 'mute-hold' it'd be cool if there was also a 'mute-defy' 
option for the 'part copy - active' function, so you could copy only 
active tracks from a source part, and then when switching to the new 
(destination) part you'd get the newly copied track-playlists playing 
along with the uncopied & unmuted original destination track-
playlists immediately, instead of having to unmute these tracks 
first. it's not a very essential function; it's just the first thing 
that came to mind when i was playing around with the new function.
for the newly-added functions; thanks a lot! they rock!

grtz Chiel

> to the 'mute-hold' it'd be cool if there was also a 'mute-defy' 
> option for the 'part copy - active' function, so you could copy 
only 
> active tracks from a source part, and then when switching to the 
new 
> (destination) part you'd get the newly copied track-playlists 
playing 
> along with the uncopied & unmuted original destination track-
> playlists immediately, instead of having to unmute these tracks 
> first.

Took me a while to get my head round what you were asking for here, 
but I think I've got it ;-)
When you do a part copy, the current mute status is copied to the 
new part. This is as if you were holding 'mute hold' while using the 
copy part function.
What I could do is add a user config option for 'keep destintation 
mutes on part copy'.
When active, the mute status would not be copied during any part 
copy unless you also held the 'mute hold' softkey and either 'part 
copy' key - giving your 'mute defy' behaviour if you don't. Or do 
you think it would be something you'd use often enough to need a 
softkey for ?

Cheers,
Colin f

> Took me a while to get my head round what you were asking for here, 
> but I think I've got it ;-)
ermm. yeah. i realised after i posted this that it wasn't really very 
clear. a bit too much caffeine i guess...but the way you describe it 
is exactly what i meant.

> When you do a part copy, the current mute status is copied to the 
> new part. This is as if you were holding 'mute hold' while using 
the 
> copy part function.
> What I could do is add a user config option for 'keep destintation 
> mutes on part copy'.
> When active, the mute status would not be copied during any part 
> copy unless you also held the 'mute hold' softkey and either 'part 
> copy' key - giving your 'mute defy' behaviour if you don't. Or do 
> you think it would be something you'd use often enough to need a 
> softkey for ?

the user config option would do just fine for me; pretty much exactly 
what i was hoping for. just set-it & forget-it, no need for an extra 
softkey.
grtz, Chiel

> So you don't think it would be a problem to have to hold 'mute 
hold' and
> either of the part copy keys to get the same behaviour as now ?
> I suppose it may even turn out to be a more sensible default option.
nope...the way the functions are laid out on the softkeys make for 
pretty easy access, even when the 'func' button is pressed as well. 
and for myself i think it'd definately be a more useful default 
option.

> the user config option would do just fine for me; pretty much exactly 
> what i was hoping for. just set-it & forget-it, no need for an extra 
> softkey.

So you don't think it would be a problem to have to hold 'mute hold' and
either of the part copy keys to get the same behaviour as now ?
I suppose it may even turn out to be a more sensible default option.

Cheers,
Colin f

hi Colin,
got some minor weirdness going on..i'm not quite sure if it's new to 
OSv3.8 or if it's been there all along, but it's getting noticeable 
now that my fingers are developing button-shaped indents..;)
when in play mode (of course..) i go to playlist-edit, push 
the 'hold' softkey to hold a certain step in the playlist and then go 
to pattern-edit mode to edit the pattern for that step, the playlist 
releases the 'hold' function as soon as i change the timebase for the 
pattern, so the playlist continues advancing. it does the same when 
stopping & restarting the p3. the stop/start thing i can understand, 
but the first one shouldn't be happening should it? neither of the 
cases are a major issue but it can be frustrating having to save a 
half-finished pattern with the risk of forgetting what you were going 
to do (keep in mind i'm in Holland and you know one of the things 
we're known for..:) ).
and i had another thing but this only happened once and was fixed by 
re-uploading the firmware; i was happily tweaking away when i think i 
hit a bad combination of keys or i just hit them too quickly, and the 
top line of the lcd went black and the bottom line went blank. i've 
had this happen before (i think it's got something to do with keys 
being hit too fast after each other?), so i do what i usually do: 
reboot and go on. but this time i got a 'bad checksum' error on 
rebooting, leading to the boot/flash screen. i hit boot and the p3 
starts up as normal, except that the playlist-edit has a weird bug 
where it seems to select random playlist steps instead of the one i'm 
tweaking when i turn the repeat or transpose pots above the step. so 
i made a sysex-dump of all patterns (no problems) and then re-
uploaded both the firmware and the patterns, after which it was fixed.
also not a major thing, but do you have any tips on how to avoid it 
in the future? i'm guessing it's the cpu getting confused when keys 
are hit too quickly after each other...which would mean i just need 
to chill out a bit. :)
grtz Chiel

> got some minor weirdness going on..i'm not quite sure if it's new to 
> OSv3.8 or if it's been there all along, but it's getting noticeable 
> now that my fingers are developing button-shaped indents..;)
> when in play mode (of course..) i go to playlist-edit, push 
> the 'hold' softkey to hold a certain step in the playlist and then go 
> to pattern-edit mode to edit the pattern for that step, the playlist 
> releases the 'hold' function as soon as i change the timebase for the 
> pattern, so the playlist continues advancing.

That's something I overlooked - a change of tbase forces a refresh of
the current playlist step that knocks off the hold bit.
Logically, I don't think it should do that. I'll fix it...

> it does the same when 
> stopping & restarting the p3. the stop/start thing i can understand, 
> but the first one shouldn't be happening should it?

The stop/start clear of hold is because the playlists are all reset to
step 1 on start.
When I was testing the hold code, I found it confusing that a restart
didn't clear it.
I guess I could add a 'keep hold on restart' option for those of a
different opinion...

> neither of the 
> cases are a major issue but it can be frustrating having to save a 
> half-finished pattern with the risk of forgetting what you were going 
> to do (keep in mind i'm in Holland and you know one of the things 
> we're known for..:) ).

Does high quality porn affect your memory ? ;-)

> and i had another thing but this only happened once and was fixed by 
> re-uploading the firmware; i was happily tweaking away when i think i 
> hit a bad combination of keys or i just hit them too quickly, and the 
> top line of the lcd went black and the bottom line went blank. i've 
> had this happen before (i think it's got something to do with keys 
> being hit too fast after each other?)

There's no reason why you shouldn't be able to hit the keys as fast as
you like.
The keys are scanned every couple of milliseconds by a timed interrupt
routine. It just updates a status table to show whether each key is
pressed or not. It would be very poor programming practice for any user
input to be able to crash the machine.

> so i do what i usually do: 
> reboot and go on. but this time i got a 'bad checksum' error on 
> rebooting, leading to the boot/flash screen. i hit boot and the p3 
> starts up as normal, except that the playlist-edit has a weird bug 
> where it seems to select random playlist steps instead of the one i'm 
> tweaking when i turn the repeat or transpose pots above the step. so 
> i made a sysex-dump of all patterns (no problems) and then re-
> uploaded both the firmware and the patterns, after which it was fixed.
> also not a major thing, but do you have any tips on how to avoid it 
> in the future? i'm guessing it's the cpu getting confused when keys 
> are hit too quickly after each other...which would mean i just need 
> to chill out a bit. :)

This sounds to me more like it could be a hardware problem - possibly a
marginal connection in the power supply that causes a brown-out
(temporary lack of sufficient voltage). That could be causing the
processor to do odd things, including possible corruption of the flash.
If it's only happening when you're rapidly pressing buttons, it could be
that the connection is fine until it receives a certain level of
physical shock through the case.
Might be worth testing this theory out. It's certainly not something
I've heard of from anyone else (cue stream of email...)

Cheers,
Colin f

Folks,

I've uploaded firmware v3.8 rev 2 to Yahoo files, with the 'hold'
setting retained during change of tbase in pattern edit.
And since I've now been using this version for a week without finding
any other bugs (obviously not looking as hard as Chiel:), I've made it
the current release.

Cheers,
Colin f

hi Colin,

> When I was testing the hold code, I found it confusing that a 
restart
> didn't clear it.
> I guess I could add a 'keep hold on restart' option for those of a
> different opinion...

not really necessary for me. the way it works at the moment is pretty 
logical and i can imagine it getting confusing when you're doing 
stuff. sort of ties in with the possibility to retain the hold-
setting when switching back to play mode that i mentioned 
before..which you solved very neatly with the quick pattern select 
function.

> This sounds to me more like it could be a hardware problem - 
possibly a
> marginal connection in the power supply that causes a brown-out
...until it receives a certain level of
> physical shock through the case.
> Might be worth testing this theory out. It's certainly not something
> I've heard of from anyone else (cue stream of email...)

i'm planning to do some tests of that nature, but i'm getting well 
underway in preparing a liveset for this coming thursday so i don't 
really want to muck about internally at the moment. but as i want to 
relocate the tempo-pot and internalize the power supply soon anyway 
i'll look at it then. but still, the quick-fix for the time being is 
just to relax a bit and stop ramming the buttons and just push them 
instead...;)

grtz Chiel