translate ms to notevalues
Translating ms to notevalues will only output a zero, however if I translate ms to ticks and then ticks to notevalues I get the correct result.
Its no big deal to have the tick stage in there but it might be confusing to some people.
weird... it seems to work sometimes now, and also sometimes the tick->notevalues thing doesn't work.
Also, it seems to be more predictable when I specify the @in and @out attributes rather than just using the first two arguments for the translate format.
Quote: Nick Inhofe wrote on Thu, 16 October 2008 20:02
----------------------------------------------------
> it seems to be more predictable when I specify the @in and @out attributes rather than just using the first two arguments for the translate format.
>
----------------------------------------------------
I ran into something like this before, and my solution was to use @in and @out. I think it always works when you do that? The arguments never seemed to work right for me.
Ok. So I think I've tracked down the root of the problem. The translate ms to notevalues seems to depend on the current transport tempo. For a lot of bpm values, translate will behave as desired. However certain tempo values will cause translate to output a 0. when going from ms to notevalues.
Here is an example patch:
Nick Inhofe schrieb:
> Ok. So I think I found the root of the problem. Translate seems to
> only behave correctly at certain tempo values. Here is an example
> patch:
the notevalues have to be bound to the set tempo, but I think putting
out 0. if it doesn't fit is plain wrong, it should pass the ms instead
unchanged. You could still [route float]...
I would vote for a different behavior as it is now...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Yes, but if you look at my example patch- the note values ARE bound to the current tempo. I'm just translating a timevalue to ms and then back. Translate will put out a 0. on certain tempo values and not others.
Here is the example again to be clear-
Nick Inhofe schrieb:
> Here is the example again to be clear-
I can confirm, seems a resolution/rounding problem.
My suggestion/feature request would be, that notevalues should be
rounded to the next tick, and if that doesn't fit to a notevalue instead
of "0.", it should give the ticks. I'd assume ticks to be a sort of a
notevalue anyway. The "0." seems to be a design bug of the object, it
doesn't make sense for me, as its plain wrong, no matter which unit you
might want to interpret it with...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Nick, thanks for tracking this down for us. I can confirm that this is an issue and we will be looking into it.
All the best,
-Ben
great! thanks for reading my post :)
2 years ago and it isn't fixed...i'm getting a 0. from time to time when
i translate ticks to notevalues
again problems with translate ms to n
i'd like to try a selfmade translation.
can someone help with a little bit math?
isn't it possible to calculate n out of ms and the bpm of the transport?
(n are beats, floating point, 6 numbers behind the .) maybe we come across
the same problems they seem have had with building the translation object.
(certain tempo values will cause translate to output a 0. when going from ms to notevalues)
O.
Hi there,
Can you post a patch? The bug that is described above is most definitely fixed. Perhaps you are experiencing something else?
If you don't have a tick value that makes sense given your current bpm, then you will indeed get a 0.
-Ben
ok, the translation was easier then i expected: ms to n
@Ben
more annoying in the moment was ms to n not working properly,
i will see if i can post something producing the "errors" with
translate. i'm getting 0. and sometimes "0" (with qoutes as output)
Sorry that you are still having some problems with it. It appears to work here as expected, but maybe you are doing something that I'm not. Please do post a patch, I'll be happy to take a look.
-Ben
fwiw, here is what works here:
-Ben
it's funny, i'm not talking about the notevalues, i just used the letter n.
i tryed to translate with it but now i noticed it behaves like a get clip_playing_position live.object (wondered why the n isn't in the translate object help umenus)
can you check that? this now with a metro is in my patch observing the clip_playing position in device_track.
I'm not familiar with the 'n' time value. Can you describe what it is you are trying to translate ms to exactly? The transport output is outputting ticks. Do you want to translate from ticks to something else?
-Ben
tried to translate ms delta times to the value type you get for the positions of notes in midiclips. where 1/16 steps look like this 0 0.250
0.5 0.75... in fact i have now a translater for that (what i posted some posts ago)
but strange that you tell me "n" isn't a shortcut for any timevalue
if someone could check the last code, and see what it outputs for him
would the translate object send an error message if it gets an unknown time parameter? edit: yes it does, it says n: bad number
you will have to do this conversion yourself. The valid time values can be found here:
good luck!
-Ben
they should really add that to the translate obj. i guess e. g. observing the clip length (start and end marker) is frequently used. now i have to write my own translators just to have a cliplength or position in bbu or ms for example.
regards.
notevalues are there for convenience to express common individual notes duration. translate ticks bbu is going to give you bars.beats.units which is probably what you need (you don't have ms coming out the raw ticks outlet of transport).