> On 05/09/2013 12:26 PM, Tom Breton (Tehom) wrote:
>> You've been using something like it for a couple of years now; meanwhile
>> I
>> already added controller commands that overlap a lot with it (that's
>> where
>> the "Controllers" menu comes from).
>
> Tom:
>
> Looking back at my records, I see that I was using volume-controller ramps
> at least as far back as version 1.7.3. I recently switched from using
> volume controllers to using expression controllers, as that seemed more
> appropriate in this context.
Heh, I also did my early composition stuff with volume before I learned
what expression vs volume was intended for.
> I originally wrote this modification simply because I needed it. I had no
> vision at the time of writing anything that could become part of the
> official package. Because my code has evolved in isolation, it is likely
> not directly applicable to the current setup. Feel free to steal anything
> that looks useful and trash the rest. I'm not committed to my particular
> way of doing things and will happily use anything that gives me the
> functionality I need.
Thank you. I like a number of things that you've done. There are also
some things I like better about what I've done - it's available for all
controllers & pitchbend, deduces controller type from the current ruler,
arbitrary selections of them can be tweaked by dialog.
I think we can have the best of both worlds with this, with judicious
borrowing.
> In my particular implementation of this feature, the location of the ramp
> is determined by selecting a series of visible events, which can be notes,
> rests, or both. Anything will do.
Right, that's the same in both. It's a good way of getting a time range.
> The number of control events is determined by the number of steps required
> to cover the ramp range. I hit an a maximum step size of four, as that
> seemed to be about as far as I could go before the individual step
> transitions became apparent.
I like that! I have been doing it the hard way, guesstimating and then
setting the number of controllers by hand. That sounds much more
convenient.
> A linear ramp positions the step events uniformly over the length of the
> ramp (and presupposes a fairly constant tempo). A logarithmic ramp uses
> exactly the same steps as the linear ramp but positions them differently,
> squashing them together at one end.
That makes sense. Thank you for explaining that.
> In its current form this code probably provides more of a working
> demonstration of possibilities than something directly useful. As I said
> before, feel free to use, discard, or ignore completely anything in there.
I like a number of things you've done, and I'm excited about merging all
of this together. I'm going to code a best-of-both-worlds (hopefully! :))
version in the next few days and put it on a branch for inspection.
Tom Breton (Tehom)
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
