i use lemur with cubase 7.5.20 on pc widnows seven with loopMIDI.
when i send midi with lemur i get some CC curves with lots of steps (with or without ad hoc connection)
this is a snapshot from lemur vs hardware.
is there somehting i must set to get it right ?
thx
Hi
What is the timebase of those curves?? Thats important . . .
Lemur is frame-based. Those steps are probably only about 16ms apart . .
The other ones are probably 2ms . . .
The Lemur is skipping values due to the timeslice - the hardware far less so . .
Think of it as data thinning . . .
What are you controlling with it? I imagine there are many things where the audible result would be negligible
Do you actually notice any sonic difference? Trust your ears and don't worry what the computer says . . .
what is controlled is quite important I think. For example, you hardly ever hear stepping in a softsynth when you control the filter. Although there are usually only 128 steps that are sent to the softsynth, the sound of the filter remains smooth as if it had a much higher resolution of 1000+ steps. There is some clever interpolation going on in softsynths today. Something that digitally controlled synthesisers from the 80's didn't have.
So I think Macciza is right when he says if you can't hear it, don't worry about it.
That was simply meant as a description of what is happening - data is being thinned - the control is moving faster then the data rate . . .
That trace probably covers all of 1 or 2 seconds - if that was a CC7 Volume control I really doubt that anyone would notice the difference . ..
The resolution of the MIDI data or whether it is OSC is not necessarily that important - that is data resolution . .
What we are seeing here is mainly temporal resolution side-effects . . .
Many things are frame-driven still these days - it is pretty standard fare ....
Its more then adequate for some things and less then adequate for others depending on a number of things . .
[quote="Macciza"]
That was simply meant as a description of what is happening - data is being thinned - the control is moving faster then the data rate . . .
That trace probably covers all of 1 or 2 seconds - if that was a CC7 Volume control I really doubt that anyone would notice the difference . ..
The resolution of the MIDI data or whether it is OSC is not necessarily that important - that is data resolution . .
What we are seeing here is mainly temporal resolution side-effects . . .
Many things are frame-driven still these days - it is pretty standard fare ....
Its more then adequate for some things and less then adequate for others depending on a number of things . .[/quote]
Oh - I understand the issue perfectly. My comment was also just a descriptor of what is happening - pedantic apologist condescension. That 'temporal resolution side-effect'? Are you seriously trying to claim this as unimportant . . . to people involved in music production? Classic!
Don't have a clue what you're trying to say with that last bit, could you be a bit more vague perhaps? Which things, specifically timing-critical things, tie their work-loop to the display framerate?
Name one.
I contend that Lemur falls exactly into the class of things for which frame-driving is wholly inadequate. And I'm pretty sure you know this to be the case. intellectual honesty . . . try it, you may like it.
Based on my exposure to Lemur so far, I would say that it is perfectly adequate for doing things like editors, non-timing-critical remote control, and some interesting display type applications. **So far**, **to me**, it does not seem particularly well-suited as a MIDI sequencer tool. If you need a sequencer or drum trigger'er or a realtime controller device, this may not be your best choice of platforms.
Whether or not future changes improve things remains to be seen, but if I have a limited amount of time in my life (I do) and too many things I want to do (I do), I will not spend many of my minutes trying to make Lemur do things it's not particularly suited for at the moment. I am having a challenging time as it is trying to create a template or two that is as robust and as clean as the type of software I write in my day job.
Back to the original topic . . And the adequacy of the Lemur data rate . . .
Not got time to go into all the details but . .
It all depends on the timescale of the original graphic (and the app it came from and how that app treats CC data) . .
I'm guessing around 50-60ms per minor division - so maybe a 250-300ms attack and 200-250ms decay phase
Lemur trace shows plateaus of say 10-30ms - Hardware shows says 2-3ms plateaus
Depending on all sorts of things and for all sorts of reasons this control data will have different effects on what it affects .
There are many things where the difference will not be noticeable /relevant/ or important - given the same basic slope but differing stepping - 2ms vs 16ms
I would think there are less things where they are noticeable and important, and in those cases it is for good reason due the nature of what is trying to be done
And then to what further purposes are the results being used? Live performance, recording, professional/amateur etc
If it is live, then as I said it makes no difference, even a small amount of noticeable stuff what matter either, the audience won't know . . .
If it is recording then it comes back to the fact of 'Is it noticeable' in what you are doing, and why is it noticeable, and what can you do about it
To me, it really doesn't matter what it 'looks' like at this micro scale, it is what it sounds like in its eventual context, that micro scale is just not that important
And all this is without bringing what the hardware in question is or what sort of data rates are common for other products or what software it is going into . ..
It might be better to change to relative controls instead, if possible, due to how they are implemented . . .
Then it may become a case of 'how to decrease' midi data flow . . .
My C4 controller sends relative CC data from the pots roughly every 60ms
I can get the same data out of Lemur at roughly every 16ms . . .
So it does kinda suggest slowing down the data from Lemur in this case??
It might be old kit, not sure if Mackies current offerings send any faster . . .
Take from that what you will . . .
Another option might be to try 14bit controllers for the extra y resolution accuracy . .
And further again . . .
More approx data rates of various gear.
Mackie C4 - ~60ms consistent
Behringer BCF 2000 ~20ms consistent(regular ~10ms but not varying between)
VMeter - ~5-8ms varying
8IO - <1ms - 3ms varying
Korg NanoKontrol - ~7-10ms varying
Quneo -depends on controller -~1-2ms for some and up to ~15ms on others
SoftStep -~1-10ms varying
And although I couldn't be bothered trying to workout Lives data rate to onscreen input ,
it was absolutely shocking with very large times and huge value jumps ...
All of these also skip values to cover range faster . . .
Based on this, and various other fundamental principles, Lemur is quite capable of holding its own as a professional controller . . .
