Easing/ramping?

[lossius]

(The following could be part of issue #14, but I believe it's better to separate the different possible additions.)

Reading through the current version of the proposal I generally believe that it looks very good and promising. I next compared the proposal as well as the discussions in the remaining open issues to the attributes we currently have for parameters in Jamoma (in the Max implementation as well as the underlying C++ library), and there's one feature used in Jamoma that is not discussed here: ramping.

What we call "ramping" in Jamoma will generally be known as "easing" in video and animation. Jamoma parameters have two attributes relating to easing:

• "ramp function" states what ramping/easing function to use. This enables us to request ramps/eases without having to explicitly express what function to use every single time. The ramp function can be changed dynamically. The goal is to implement all of Robert Penner's Easing Functions, as well as additional functions that are mostly useful for e.g. audio fade in/out, crossfades and envelope shaping.
• "ramp drive" states what timing mechanism should drive the ramping/easing. The presence of this parameter is mostly due to the fact that for video one generally wants new values to be calculated just in time for the next frame, while audio might need to happen at a faster (and possible audio) rate.

I don't think that OSCQueryProtocol needs to address the timing mechanism (the "ramp drive" in Jamoma parlance) as this have to be implemented in the model that performs the actual easing, and the specific implementation can be transparent to the rest of the world..

However, the question is whether it might be useful to cater for ease/ramp functions in OSCQuery? I don't currently have a clear position on this myself, but it seems worth considering.

I can imagine all of this being implemented differently in other applications as compared to Jamoma, E.g. an application might not operate with a default ease function that is an attribute of the parameter, but instead ease has to be expressed explicitly every time an ease is requested. Furthermore I believe that this question will become increasingly relevant if one envisage OSCQuery not only as a protocol used to query states and presets, but also as a protocol that can be used for remote authoring of applicaitons.

@mrRay : Do any of this at all seem relevant to the use of OSCQueryProtocol with VDMX? If so it would be an indicator that it might be worth considering. If not, maybe it's an indication that this is something that does not necessarily belong here.

Cheers, Trond

[mrRay]

"However, the question is whether it might be useful to cater for ease/ramp functions in OSCQuery?"

question: do you think this needs to be built into the spec, or do you think it can be implemented with the spec? in other words, could we use a description like this (a string from a list of choices- ramp function names- followed by a float) to handle the ramp-related message you'd like to pass?

{
"DESCRIPTION": "the easing function to use, followed by the value to ease to",
"TYPE": "sf",
"RANGE": [
    [
        null,
        null,
        [
            "easeInSine",
            "easeOutSine",
            "easeInOutSine",
            "easeInQuad",
            etc.
        ]
    ],
    [
        0.0,
        1.0,
        null
    ]
],
etc.
}

...if this doesn't cover the functionality you had in mind, could you please explain what you'd like to see handled differently a bit more?

"Do any of this at all seem relevant to the use of OSCQueryProtocol with VDMX? If so it would be an indicator that it might be worth considering. If not, maybe it's an indication that this is something that does not necessarily belong here."

no, but i've already made a number of changes and additions to this proposal that are irrelevant or redundant in vdmx, and i'm sure there will be more before we're done. the things i expect to be handled in the application layer are frequently things other people expect to be handled by the protocol, and vice versa- i assume everybody's making some adjustments and compromises, and we'll all meet somewhere in the middle...

cheers : : ray