> regarding the union for the models. I doubt this will work properly
> with complex data types like classes (how do you decide which
> constructor to call when?). Unions date back to times where you had
> integral data types only and messed around a lot on bit level. I don't
> think we should add more complexity here just to save a few bytes of
> memory. What one could do is to merge the two knob models and define
> the behaviour via a separate property ("isTempoSynced"). However as
> usual one needs to take care of compatibility here as this will change
> the data files (and existing files have to be converted).Ok, C++11 unions have Ctors now, but well ;) I was just asking because I wanted to understand why there are multiple models. I guess there's always only one model chosen, which is dependent on the models data type, correct? > What do you mean by " The controller's incoming values will be scaled > logarithmic (e.g. an LP could be sine-controlled logarithmically)"? Do > you plan to change the controller or (as suggested) the behaviour of > the models when they read/process data from automation patterns or > controllers? As suggested: the controller sends out data, and the incoming data *at* the model *from* the controller is then scaled. Well, what do you think: Should knobs with logscale values also have their GUI scale logarithmic? I.e. if you turn the knob half way up it has *not* half the maximum value? We have not talked about it, but I think it would be very intuitive. ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
