Forum Replies Created
-
Posts
-
Sounds great!
Maybe you want to take this into account (I am currently working on a Lua based example for this…):A point is specified by
– min, max and default value for each axis
– linked point for each axis
The rules are implemented on the level of the envelope control, a point itself contains no control logic. An ADSR envelope would be of type time/level and treats it´s points as a left-to-right sequence. Rules for handling are as follows:
If a point has a range on an axis (given bei min/max value), it is moveable on the axis. If a point has a linked point, the envelope updates the point position when it updates the linked point. The ranges set the dimensions of the bounding rectangle for each point.
Take the decay/sustain points as an example:
Decay gets min/max values that make it moveable on both axis. Decay is linked to Sustain:Y. Sustain gets min/max:X = MAX, thus is not moveable on the x-axis. Sustain is linked to Decay:Y. Now if you move Decay on the y-axis, sustain will follow. If you move sustain on the y-axis, Decay will follow.As I said, I´m working on an example for that. The goal is to implement one ruleset on the envelope control level, and then set it´s character (ADSR, DADBSSR…) by adding points configured by min/max and linked points. Let´s see how this works out 🙂
He did. An ADSR envelope.
Sorry, I quoted wrong so didn´t make my point clear… I was rather refering to
The problem i’m facing with all that in mind is how to limit a point on the canvas, it sometimes need to be dependant on other points and sometime it needs to move freely around.
. And that also in connection with his statement that a sequence of typed points would be a no-go… The EQ envelopes are the only ones I could imagine where each point can really move freely without any sequential dependency.
You are right about the rectangular regions. They are therem, whether you paint them or not. They define the bounds a point can move within. And even if you leave points aside and think resizeable rectangles, the changellenge is the same.
Also one point can alter the position of ALL points, for example in a ADSR envelope if you move the attack point all others should follow it, that is keep the same distance from the attack point, but some envelopes need for the points to stay in place.
Can you give an example? I can think of envelopes that control equalizers, like in the cubase mixer. But that would be a different type of envelope I think, because the x-axis is a value line (frequency), not a timeline, and so all points would be valid on the entire range (axis that is..).
Your document assumes a sequence of messages (a fact that one type of point can’t occur before/after a different point), i think that’s a no go. All points should be of the same type, the set of properties should define each point and make it behave in a certain way.
Yes and no… With the set of properties I defined all points would be of the same type. Only this leaves to configuration user to define the different types by setting the properties correctly. The types I defined would take that away from the user but would of courxe make code logic more complicated. That´s an option, not a must.
I can imagine point templates, like your types, that is all points are “default” but you can apply a set of properties from a template to make it behave like one of the types (just thinking out loud).
This would be the set of properties I defined. If you look at the type definitions then for the Default type all properties are enabled. So any other type is just a subset of these properties and could thus be configured setting the correct values.
(Don´t get me wrong, I do not consider my document to be the final solution!)The biggest problem is how to apply bounds to where the point can movee, the X/Y axis lock is the obvious one.
I am not so sure about that. The Y axis of points can never overlap. The sole dependency lies between the X coords of the points. Each point can have a maximum bounds width of maxValueX*factorX. The bounds X origin is always previous point positionX. Still the only property to set is the maxValue and whenever these properties of a point change then the factors and poisitions have to be recalculated.
There is stuff like the SUSTAIN parameter, that defines the level and not the time, with that parameter the Y values of decay needs to move to represent how the envelope really looks like (sustain is more the line that connect release and decay and not a point).
I would say yes and no again here. The sustain is the point to the right of the line. I think it is a matter of comfort that in most implementations you can alter the sustain level with the decay point. The sustain point as well as the line that is drawn to the decay point is a visual aspect. Decay is a time parameter only. So it is actually incorrect to call the decay point decay if it can also alter a level. The decay point in envelope controls is always a control for decay and sustain at the same time. And this is the reason why I think that an envelope control must be aware of the type quality of a point. But only for the visual aspects so to say…
There are also weird multi point envelopes like the Casio CZ series has with a level,rate parameter for each point
Yes, I also pointed that out at the end and left the solution to this open..
It’s complicated, i’d like the thread to become more of a discussion i can use as a way to get this right. So if anyone has any ideas, or maybe can show me how it’s done somewhere else (and that is a good implementation) i could have a look. Anything that will help.
This sounds a bit like nothing I said made any sense..?
Hello again,
I´ve attached a text document with my design considerations.
I hope it´s readable as I am not a native speaker…Hi all,
just thought I should add this because it fits the topic:
modulator:getMidiMessage() will return nil when the modulatorIsStatic (“Modulator does not react to value changes”) property is set to 1 (“Static”).
Thanks for your quick reply atom!
I guess by “complicated” you are referring to the user´s point of view?
I see what I can put together as a descriptive design. I am really interested in this because envelope controls have always been what I was missing from similar applications, plus it would greatly enhance Ctrl panels and take off the need of the creators to script their own controls…
