Are you having these problems when switiching SECTIONS or just PATTERNS?
If the latter, I would speculate that it's a memory problem, not a cpu one...
You could experiment, and see if the same sequence data, playing back
glitch-free
when switching sections, doesn't when switching patterns. If so, it's probably
a function of how fast the RM1x can cue up the new patterns into memory. Of
course this is just an educated guess.
Please forgive the ruder part of my email, I'm just sick of people with 20/20
hindsight demanding the impossible from their equipment. I think your idea
about
note/gate time is a good one. And I misunderstood you, i thought you were
talking about having a bunch of data triggering at the start of a pattern (e.g.
patch change messages and such), which will cause timing delays on any midi
rig...speaking of this, are the glitches only happening when you have multiple
tracks on the same channel? Do they go away if you asign the tracks to
different channels? And, are the delays less noticible when using internal
sounds?
-Sean M.
> A more
> user-friendly solution would simply be that if the sequencer reaches the end
> of a pattern, and some notes are still holding, even if the user has opted
> to switch to a new pattern, scan back through the original pattern and
> locate the appropriate note off and then send it at the appropriate time.
> Granted, this would take more processing power than the current
> implementation, but if you only had one or two notes that had to be held,
> the extra amount of CPU needed would be negligible. From a ground up
> standpoint, an easy way to impliment this would be to have the sequencer
> interpret MIDI data internally the way it is displayed in the RM1x Edit
> screen. Instead of using separate note on and note off messages, have the
> internal memory use a note and gate time storage meathod. When data for a
> pattern is sent to the processor it would play the note and "look" at the
> stored gate time, and then say to itself, "ok, I have to send the off
> message for this note in 480 clock ticks." Basically, the processor would
> know how long its going to be holding a note from the moment it plays it
> instead of just holding a note until its told to stop. In the end, the user
> interface could be left just the way it is now, but by changing how the OS
> operates underneath, there would be no need to have held notes cut off when
> a pattern is changed.
>
> >>Here's another quirck I've found in the RM1x. If you have a bunch of
> >>tracks all sending their data on the same MIDI channel, you can run into a
> >>timing clitch when you first switch to a new pattern. Readying the new
> >>pattern, and merging all the track data to the same channel must bog down
> >>the RM1x processor just a little too much.
> >
> >ANY midi sequencing would "suffer a timing glich" under the conditions you
> >just described: again, its the limits of the midi spec, not of the RM1X.
>
> The timing glitch in the RM1x is not a limit of the midi spec. Granted,
> merging MIDI data will always cause some sort of delay, but the length of
> the timing delay on the RM1x is very, very noticable. Even when it only has
> to merge a small amount of note. This is caused by one of two problems. 1)
> The RM1x's CPU simply doesn't have the power to ready a new pattern and
> continue merging data at an audibly smooth rate, or 2) The CPU has enough
> power, but the software isn't taking advantage of it.
>
> >Please learn a little more about Midi before you slag off an excellent
> > >sequencer.
>
> I know plenty about MIDI. And I'm not trying to "slag" the RM1x. It is an
> excellent sequencer in many aspects, but its also far from perfect. The
> biggest problems I have with it are...
>
> A. Yamaha appears to have put a CPU in it that is just barely adquate to
> handle run-of-the-mill sequencing tasks. (Or its possible the CPU has
> plenty of power, and its an ineffecient OS that is the culprit.)
>
> B. Yamaha has not made any apparrent effort to actively listen to users and
> continue to improve and upgrade the RM1x's OS. I have to believe that the
> RM1x's OS can probably be optimized so much more than it currently is. Just
> look at how a company like Access has been able to continually squeeze more
> and more out of the Virus.
>
> C. I'm also concerned about the construction quality of the RM1x. I've had
> my RM1x for quite some time, and I've treated it with the utmost care, but
> I'm starting to see some wear. Buttons are sometimes double triggering, or
> not triggering at all, and my backlit display is starting to dim. (And yes,
> I've checked the contrast knob.)
>
> ---
> Positronica
>
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
