Analogue-sequencer

Hi Colin

On my machine the latest beta v3.1.006 beta 34 does not list all aux
destinations properly - it just lists a few of them. I used midiOX to load
it which seemed fine - I wonder if anyone else has this issue?



After having the P3 for 6 months, in many way it fits how I think like a
glove but I also have a couple of comments.



3. For me the great limitation is that I can't backup a single bank to a PC
which makes track backing up really messy and makes me nervous about losing
my masterpieces - a flash card on which you could back up or load single
banks would be killer, basically I'd like 100 banks on my P3  - of course
naming them would be a problem



2. Some kind of quick solo mode when in pattern edit would be cool (like
holding down run, or pressing run a second time?)



3. In play mode if I select a group of parts play the P3 automatically copes
the mute status of the first track over to the others can I stop it doing
this? This normally what I want but not always

cheers

Richard


----- Original Message -----
From: "colinfraser_com" <colin@colinfraser.com>
To: <analogue-sequencer@yahoogroups.com>
Sent: Thursday, December 15, 2005 2:46 PM
Subject: [analogue-sequencer] New beta in files


> Folks,
>
> I've uploaded v3.1.006 beta 34 to Yahoo files.
> This build covers all the technical changes I'm planning on making
> before the next release build - there are just UI things to add,
> assuming there aren't any problems in this one.
>
> Feedback is always welcome with P3 betas - even if you install it
> and have no trouble at all, I'd like to know. Otherwise I can't be
> sure whether it all works perfectly, or nobody tried it.
>
> The most recent change is new external MIDI sync handling code,
> which should allow P3 to sync to dodgy PC based sequencers that send
> out clock bytes with the regularity of radioactive decay.
> It now queues up clock bytes, and handles them at maximum tempo if
> they arrive in clumps.
> I don't have any dodgy PC sequencers in my studio, so it would be
> nice if afflicted persons could confirm this resolves the issue
> (Miguel, this could save you the MIDI-Ox workaround).
>
> There are some major internal changes to the way P3 handles poly
> patterns.
> For mono patterns things will be exactly the same, but if you are
> using aux notes, a couple of things are different.
>
> First, multiple auxes set to the same note are thinned out, so there
> is only a single note message for each note number.
> This eliminates unneccessary use of MIDI bandwidth, and makes life
> easier for poorly written synth OSs that struggle with multiples of
> the same note...
> There's now a limit of 8 notes that can be played by each track -
> you can achieve this by pairing two tracks together, with aux A on
> one track redirecting all auxes to the second track and the other
> three auxes doing aux notes.
> Adding those three to the four aux notes plus one main note on the
> second track makes eight.
> I have also changed the behaviour of the 'aux note abs Xd' and 'aux
> note rel Xd' events which are renamed 'aux note abs xF' and 'aux
> note rel xF'. xF = no FTS
> Force-to-scale does not apply to these aux notes, but the current
> part transpose and playlist transpose settings now do.
> This seems a lot more logical to me, but if you find it stops you
> doing something useful, let me know.
> Another change is the rel aux notes are now calculated based on the
> FTS'd value of the primary note, not the stored value.
> This makes more sense if you are using 'aux note rel xF' to do
> fixed 'chord memory' type effects against a root note pattern that
> is being forced to scale.
>
> One other change in this build is not at all obvious unless you
> check P3s MIDI output on an oscilloscope.
> After recent discussion about MIDI delay, I decided to make sure
> that there was the absolute minimum of CPU latency in P3s MIDI
> output, so the notes come out as fast as the MIDI bus can take them.
> I found that with heavy use of CPU intensive aux events and all
> tracks active, CPU latency was reaching 3ms in some cases.
>
> A re-ordering of the way each clock pulse is handled has eliminated
> this, by moving all aux event processing from the start of each
> clock pulse to the end of the previous one.
> Personally I'm not sure I hear any difference even with quite a busy
> group of tracks triggering percussive sounds, but if you think this
> build is any rhythmically tighter, let me know.
>
> Best regards,
> Colin Fraser
> Sequentix Music Systems Ltd
> http://www.sequentix.com
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>