Analogue-sequencer

We used my P3 as a master MIDI clock for about 5 or 6 of the rigs on a
couple of tunes at Different Skies. There were several times when one
of the rigs would not be ready to receive clock and I'd have to stop
and start to generate a start message.

Is there a way to do a one shot start at Gbar while the P3 is running
without having to stop and start the P3 itself? Is this what the sync
command is for?

-Jim

> Is there a way to do a one shot start at Gbar while the P3 is running
> without having to stop and start the P3 itself? Is this what the sync
> command is for?

Hmm... you weren't discussing this on the flight with Paul ?
Re-sync of MIDI and DIN outputs is something we've spoken about recently.
I thought of doing it some time ago, not so much as a performance feature,
but so I can switch between play and edit modes on my x0x drum machines
without having to stop everything.
Once I decide upon a suitable UI for it, I'll put it in.
The 'sync' function in pattern edit is just a manual pattern reset for that
track only.

Best regards,
Colin Fraser
Sequentix Music Systems Ltd
http://www.sequentix.com

> Is there a way to do a one shot start at Gbar while the P3 is running
> without having to stop and start the P3 itself? Is this what the sync
> command is for?

OK, I've implemented slave re-start in a test build, but it threw up a
couple of questions...
Currently FUNC+RUN while running causes a STOP to be sent on the last beat
of the current Gbar, followed by a START on the first beat of the next Gbar.
I tried sending the STOP on the last clock pulse of the Gbar, but that
didn't give my 303 enough time to get its head around restarting...

The first question is, should the FUNC+STOP send the STOP *immediately*,
rather than trying to leave slaved devices running and reset them with Gbar
?
Second question is, should I require a second press of FUNC+STOP to arm the
restart on the next Gbar - meaning you could stop slaved devices, and leave
them stopped for several Gbars, before bringing them back in in sync ?

Best regards,
Colin Fraser
Sequentix Music Systems Ltd
http://www.sequentix.com

--- In analogue-sequencer@yahoogroups.com, "Colin f" 
<colin@c...> wrote:
> Currently FUNC+RUN while running causes a STOP to be sent 
on the last beat
> of the current Gbar, followed by a START on the first beat of the 
next Gbar.

That would essentially automate how we were resyncing the 
other players at DS. But I think all we really needed was a start 
command on the Gbar. I can see why you might want to generate 
a stop command first; if the other machines are already running 
and you want to pull it together. 

> The first question is, should the FUNC+STOP send the STOP 
*immediately*,
> rather than trying to leave slaved devices running and reset 
them with Gbar
> ?

*Immediately* seems a little more flexible and intuitive.

> Second question is, should I require a second press of 
FUNC+STOP to arm the
> restart on the next Gbar - meaning you could stop slaved 
devices, and leave
> them stopped for several Gbars, before bringing them back in 
in sync ?

If I'm reading this correctly FUNC+RUN = Stop on last beat of 
Gbar, Start on 1st beat of next Gbar, while...
FUNC+STOP (1) = Immediate Stop
FUNC+STOP(2) = Start on 1st beat of next Gbar

That's useful and would work but I would probably just 
remember that FUNC+STOP is immediate stop and 
FUNC+RUN starts you at the next Gbar. What does midi gear do 
when receiving 2 stop commands in a row? 

Now that I think about it, I'd probably have to do the 2nd 
FUNC+STOP for the restart, otherwise the next time I'd think I 
was doing an immediate stop, the P3 would  actually send a 
start at the next Gbar.

OK, so FUNC+RUN is more panic mode, while FUNC+STOP is 
more musical breakdown mode. I can learn that;^)

-Jim

> 
> Best regards,
> Colin Fraser
> Sequentix Music Systems Ltd
> http://www.sequentix.com

Colin f wrote:

> 
>  
>
>OK, I've implemented slave re-start in a test build, but it threw up a
>couple of questions...
>Currently FUNC+RUN while running causes a STOP to be sent on the last beat
>of the current Gbar, followed by a START on the first beat of the next Gbar.
>I tried sending the STOP on the last clock pulse of the Gbar, but that
>didn't give my 303 enough time to get its head around restarting...
>  
>
I would personally NOT want a stop command sent at all because I often 
have multiple synced devices and wish to be able to stop them manually 
but restart them smoothly and individually when needed. If the process 
sent stop first, devices that I didn't stop manually would stop too, out 
of my control.

>The first question is, should the FUNC+STOP send the STOP *immediately*,
>rather than trying to leave slaved devices running and reset them with Gbar
>?
>  
>
The "safe stop" function works fine now, I wouldn't personally tamper 
with it. If you want to resync stuff, it will be because you have 
manually stopped it (all devices should be manually stoppable, in my 
experience, so the P3 needn't worry about that aspect of things).

>Second question is, should I require a second press of FUNC+STOP to arm the
>restart on the next Gbar - meaning you could stop slaved devices, and leave
>them stopped for several Gbars, before bringing them back in in sync ?
>  
>
Just doing the Func+Run thing during playback to send a Start on the 
next GBar would provide all the functionality I can currently dream up...

Paul

---
Paul Nagle / Soft Room Music / Bogus Focus Records / Binar / Headshock / The Joint Intelligence Committee
        www.softroom.co.uk / www.BogusFocus.com / www.JointIntelligenceCommittee.com

> I would personally NOT want a stop command sent at all 
> because I often 
> have multiple synced devices and wish to be able to stop them 
> manually 
> but restart them smoothly and individually when needed. If 
> the process 
> sent stop first, devices that I didn't stop manually would 
> stop too, out 
> of my control.

I'm not sure that all devices will restart if they receive a START without
having received a STOP.
Will need to check...
 
> >The first question is, should the FUNC+STOP send the STOP 
> *immediately*,
> >rather than trying to leave slaved devices running and reset 
> them with Gbar

> The "safe stop" function works fine now, I wouldn't personally tamper 
> with it.

I wrote that wrong... I meant FUNC+RUN would send the stop, assuming P3 was
running.
Essentially, FUNC+RUN would be toggling MIDI clock off and on, with the on
synced to gbar.

> Just doing the Func+Run thing during playback to send a Start on the 
> next GBar would provide all the functionality I can currently 
> dream up...

If it works...

Best regards,
Colin Fraser
Sequentix Music Systems Ltd
http://www.sequentix.com

--- In analogue-sequencer@yahoogroups.com, Paul Nagle <softroom@b...>
wrote:
> Just doing the Func+Run thing during playback to send a Start on the 
> next GBar would provide all the functionality I can currently dream
up...


This is also all we would've needed at Different Skies, as the folks
who needed a start were all manually stopped rigs.

-Jim
 www.touchxtone.com

> > Just doing the Func+Run thing during playback to send a 
> Start on the 
> > next GBar would provide all the functionality I can currently dream
> up...

> This is also all we would've needed at Different Skies, as the folks
> who needed a start were all manually stopped rigs.

That makes sense.
Not much use to me though - the devices I need to stop and restart don't
have manual control of stopping when they are slaved.
I suppose I could make the sending of stop optional, or on a different key
combination.

Best regards,
Colin Fraser
Sequentix Music Systems Ltd
http://www.sequentix.com