hello
i face a little prob here with my midi keyboards midi clock sending.
i use uf7 cme. its clock sending is not accurate as i can see when i use it in creamwares synths.
for example if i set a synth to external sync i see its tempo very trembling around the tempo set. 120 for ex. is 121,06.......119,.... 120,..... 121.... 119,............... and it causes pops in the sound of the synth. midi filterring does not help in that case. midi filter helps though when i pass the midi clock through it and send it to a sequncer.
any suggestions in getting a very stable midi value?
problem with midi clock accuracy
it is a bug. 
i tested it by giving a synth the clock of another synth wich shows accurate valu.
i set 404 internal clock 111 and sent clock to prisma. set prisma to external clock and prisma shows the shifting trembling bosa nova baby value.
too bad.
or is there a fix by setting a scopes file like cset ini or whatever?
i tested it by giving a synth the clock of another synth wich shows accurate valu.
i set 404 internal clock 111 and sent clock to prisma. set prisma to external clock and prisma shows the shifting trembling bosa nova baby value.
too bad.
or is there a fix by setting a scopes file like cset ini or whatever?
-
hubird
my MachineDrum and Monomachine show wild and fast tempo variations behind the comma when sinced to Cubase...
Like does Wavelength' OP8, as it shows decimals
It's absolutely nothing compared to natural band life fluctuations tho, if that's an arguement
Ableton's clock is said to be worth than Cubase's.
Like does Wavelength' OP8, as it shows decimals
It's absolutely nothing compared to natural band life fluctuations tho, if that's an arguement
Ableton's clock is said to be worth than Cubase's.
The only thing that should be affected in Scope by external clock is anything that's using a delay line and is synced to external tempo. This means delays and some chorus/flange style effects, etc. will definately have little 'glitches' as the delay lines are kept in 'sync'.
So, I recommend that you use internal sync, or if you want a synth's lfo's etc to really track tempo changes in an external sequencer then you should try skipping the built in tempo related synth effects and use external effects that are not synced externally. How to work around tempo changes with these external effects will vary, if indeed you truly want things to be in sync with them. Sometimes the best solution even is to record your part and do the effects in software with plugins that have an easier time keeping up with tempo changes.
Scope's midi (async) code runs on the cpu and much like anything else that passes through the cpu & system bus in modern OS's the timing isn't 'realtime'. So it is not in fact a 'bug' per se, but rather the innaccuracies of modern 'multitasking/multithreading' non-realtime Operating systems. There certainly are things that could could be done in each Scope device to account for a fluctuating external clock, but at the expense of additional dsp overhead and perhaps even some innacuracy in tracking tempo changes.
This is why some people still use Notator or Cubase on an Atari, and say they have better timing than a computer that's 12 yrs more 'progressed' as they are 'realtime' rather than doing task swapping internally.
In fact with the midi protocol itself, if you are doing ANYTHING other than simply sending midi clock through a given midi port, all the other information (be it Notes, midi cc or worse yet sysex/nrpn) is going to cause a wider degree of fluctuation than you'll see with software based midi (the sequencer source & destination drivers). This is because MIDI operates at a rather low fixed rate (31.25 KHz) and is a serial protocol, with each MIDI message being at least a certain bytelength. So every note on & off or cc value will inherently delay the next midi clock byte by a few milliseconds (not to mention sysex & nrpn can vary in size and are quite large so they can delay other MIDI messages quite a bit more).
To get around this issue (external clock sync), some external synths & devices (such as my virus) will simply take a mean or average of the incoming tempo clock and apply it to its internal processes. There's no reason that Scope based devices couldn't do this, and in fact there are ways the end user can accomplish this in the Modular, but most devices don't do it by default.
Also you mention Ableton live syncing to external tempo without any issues. This hasn't been my experience so I'm curious... When I've attempted to sync Ableton to ANY sort of external timecode, be it midi clock or SMPTE etc, any variations cause glitching not just in delay based plugins but even in its internal audio engine (any audio clips playing). I have to admit I haven't tried with v6, but versions 2-5 of Live exhibited this. The only device I have had that presented a stable enough clock to make using external sync in Live work was an MMT8, and only when sending no other data on that midi cable.
So, I recommend that you use internal sync, or if you want a synth's lfo's etc to really track tempo changes in an external sequencer then you should try skipping the built in tempo related synth effects and use external effects that are not synced externally. How to work around tempo changes with these external effects will vary, if indeed you truly want things to be in sync with them. Sometimes the best solution even is to record your part and do the effects in software with plugins that have an easier time keeping up with tempo changes.
Scope's midi (async) code runs on the cpu and much like anything else that passes through the cpu & system bus in modern OS's the timing isn't 'realtime'. So it is not in fact a 'bug' per se, but rather the innaccuracies of modern 'multitasking/multithreading' non-realtime Operating systems. There certainly are things that could could be done in each Scope device to account for a fluctuating external clock, but at the expense of additional dsp overhead and perhaps even some innacuracy in tracking tempo changes.
This is why some people still use Notator or Cubase on an Atari, and say they have better timing than a computer that's 12 yrs more 'progressed' as they are 'realtime' rather than doing task swapping internally.
In fact with the midi protocol itself, if you are doing ANYTHING other than simply sending midi clock through a given midi port, all the other information (be it Notes, midi cc or worse yet sysex/nrpn) is going to cause a wider degree of fluctuation than you'll see with software based midi (the sequencer source & destination drivers). This is because MIDI operates at a rather low fixed rate (31.25 KHz) and is a serial protocol, with each MIDI message being at least a certain bytelength. So every note on & off or cc value will inherently delay the next midi clock byte by a few milliseconds (not to mention sysex & nrpn can vary in size and are quite large so they can delay other MIDI messages quite a bit more).
To get around this issue (external clock sync), some external synths & devices (such as my virus) will simply take a mean or average of the incoming tempo clock and apply it to its internal processes. There's no reason that Scope based devices couldn't do this, and in fact there are ways the end user can accomplish this in the Modular, but most devices don't do it by default.
Also you mention Ableton live syncing to external tempo without any issues. This hasn't been my experience so I'm curious... When I've attempted to sync Ableton to ANY sort of external timecode, be it midi clock or SMPTE etc, any variations cause glitching not just in delay based plugins but even in its internal audio engine (any audio clips playing). I have to admit I haven't tried with v6, but versions 2-5 of Live exhibited this. The only device I have had that presented a stable enough clock to make using external sync in Live work was an MMT8, and only when sending no other data on that midi cable.
hey valis. how is this done?To get around this issue (external clock sync), some external synths & devices (such as my virus) will simply take a mean or average of the incoming tempo clock and apply it to its internal processes. There's no reason that Scope based devices couldn't do this, and in fact there are ways the end user can accomplish this in the Modular, but most devices don't do it by default.
Scope, Android, Web, PC Plugins and Sounds:
http://www.oceanswift.net
Music
https://faxinadu.bandcamp.com/
http://www.oceanswift.net
Music
https://faxinadu.bandcamp.com/
it is bug.
fl studio midi sync is stable as a vst.
ableton 6 stable.
creamware synths internally stable.
if i connect a synth internally synced(stable midi) to another synth that is externally synced by the prvious on the last one is trembling.
no mater if i use midi filter if i send only clock.
bug bug bug!
and to add this. why creamware gives the option of externally syncronizing almast all of the synths that cost a fortune if this does not work by giving glitches pops and crackles to their sound.
sorry but it is very bad not giving us useful updates or patches or whatever computer and sound programmers could fix.
REALLY
START WRITING IN CAPITALS AS MY FIRST POST
come on.
fl studio midi sync is stable as a vst.
ableton 6 stable.
creamware synths internally stable.
if i connect a synth internally synced(stable midi) to another synth that is externally synced by the prvious on the last one is trembling.
no mater if i use midi filter if i send only clock.
bug bug bug!
and to add this. why creamware gives the option of externally syncronizing almast all of the synths that cost a fortune if this does not work by giving glitches pops and crackles to their sound.
sorry but it is very bad not giving us useful updates or patches or whatever computer and sound programmers could fix.
REALLY
START WRITING IN CAPITALS AS MY FIRST POST
come on.
Since Midi is a control signal that can be separated into component parts within Modular, I would think you could simply extract the tempo clock and 'smooth' it using a lowpass/slew limiter? Or perhaps you could go beyond that and toss in a bit of math to do control the ballistics and come closer to a 'mean' result (think RMS, exponential rather than linear) which would be more stable if you experience occasional spiking.faxinadu wrote:hey valis. how is this done?To get around this issue (external clock sync), some external synths & devices (such as my virus) will simply take a mean or average of the incoming tempo clock and apply it to its internal processes. There's no reason that Scope based devices couldn't do this, and in fact there are ways the end user can accomplish this in the Modular, but most devices don't do it by default.
How is FL STudio's midi sync 'stable as a vst'? You've lost me here. I am not sure that your references for how midi clock works are 100% comparable to this situation? You need to explicitly test everything with the same external clock source. It's quite possible that certain applications are more forgiving in 'interpolating' midi clock through some balistics tracking (as I attempted to explain above) but in my experience Logic, Live and quite a few other 'professional' applications that I have used suffer from the exact same issue you mention when attempting to sync to external clock.ARCADIOS wrote:it is bug.
fl studio midi sync is stable as a vst.
ableton 6 stable.
creamware synths internally stable.
if i connect a synth internally synced(stable midi) to another synth that is externally synced by the prvious on the last one is trembling.
no mater if i use midi filter if i send only clock.
bug bug bug!
and to add this. why creamware gives the option of externally syncronizing almast all of the synths that cost a fortune if this does not work by giving glitches pops and crackles to their sound.
sorry but it is very bad not giving us useful updates or patches or whatever computer and sound programmers could fix.
REALLY
START WRITING IN CAPITALS AS MY FIRST POST
come on.
Also it occurs to me that perhaps there's a MIDI clock issue with your rig that goes beyond what the rest of us experience? In your initial post you showed that it has 1-2% deviance, which is normal in my experience. Meaning that the values to the right of the decimal (120,XX in 120bpm) fluctuate a lot, and then the 1's digit does too occasionally as a value wraps over. Do you experience significantly more than this? If not then this is indeed NORMAL, although I can tell not desired in your case (nor in mine to be honest).
I gave a technical description on why sticking to the technicals of the midi spec would lead to clock fluctuations in any circumstance, made worse if you're manipulating a lot of controls on the device sending the clock. I also threw in my understanding of why Async/Midi related data fluctuates a bit more once in the Scope environment.
What you really seem to be saying is that you want smoothed tempo interpolation in the Creamware synths when synced externally, and you find the lack of this 'feature' a 'bug'. I call it a 'feature' and am less frustrated and more inclined to listen to the other workarounds. Asking for that 'feature' in future devices might not be a bad thing. But as things stand this is how the tools you have operate. I can't change this and I suspect Creamware isn't in a position to do so in the near future either.
Really if an aspiring developer here wanted to bring a nice tool out I can see a midi clock 'smoother' making someone very happy.
I don't know if this would be as successfully applied to existing devices as it could be to new ones.it might be it is just a simple setting.
and what if it is not simple. this does not make an excuse of this bad reaction whrn externally cyncronized.
terrible. it seems like lightwave for instance is like a heavy rewired program. does not make sence.
told you about the simple test from synth to synth.
and what if it is not simple. this does not make an excuse of this bad reaction whrn externally cyncronized.
terrible. it seems like lightwave for instance is like a heavy rewired program. does not make sence.
told you about the simple test from synth to synth.
You miss the point though. Synth to synth you are not limited by the midi data clock, as that exists on the HARDWARE midi connection, as 31.5khz datarate. The OS also handles the moving of the midi data from the hardware interface to the Scope application, so high cpu load can also interfere. Connecting one synth inside Scope to another completely bypasses both of these bottlenecks that your CME controller passes through.
valis you do not understand what i mean.
i said that it ALSO happens when using only synths WITHOUT hardware controller.
1st just try to put a 404 in whatever tempo you like internally syned.
lets say 100.
now put a second 404 connected with the 1st 404 and if you set the second 404 to sync externally from the 1st 404 then you will see the same bad accuracy happen to the second 404.
this is nonsense. it should defenatlly not happen.
no hardware sync. just creamware synths.
BIG BIG BUG
i said that it ALSO happens when using only synths WITHOUT hardware controller.
1st just try to put a 404 in whatever tempo you like internally syned.
lets say 100.
now put a second 404 connected with the 1st 404 and if you set the second 404 to sync externally from the 1st 404 then you will see the same bad accuracy happen to the second 404.
this is nonsense. it should defenatlly not happen.
no hardware sync. just creamware synths.
BIG BIG BUG
-
Liquid Len
- Posts: 652
- Joined: Tue Dec 09, 2003 4:00 pm
- Location: Home By The Sea
I found MIDI timing for PC sequencers got completely degraded after Windows 9x/ME. I've actually considered going back.. (the horror! the horror!) I admit, I was pretty pissed off about this bug, which I consider the worst single bug of the platform (of course no platform is bug free). I can sync my MS2000 to Cubase and it achieves fairly good timing. I don't know enough to say for sure, but I would not be surprised to find out that microsoft's architecture makes it very difficult to achieve proper timing.
-
hubird