[gmpi] Re: GMPI reqs draft 1 (part 2) for review, paragraph 4.10

  • From: "Didier Dambrin" <didid@xxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Tue, 4 Jan 2005 17:46:59 +0100

I haven't followed the whole discussion so I hope I'm not OT:

My opinion:

Defining events with an optional ramping is better. Why?

In practice, no one would code his processing to support a sampled source of parameters. This would require checking parameters for each sample (or short block of samples), and we all know that it's not doable in practice. Some simple IIR filters require huge coefficients computations when their parameters change.

Meanwhile:
-having a set of events allows a processing to be divided into chunks, so that the inner processing will process from an event's timestamp to the next one


-linear ramping isn't CPU costy, and it's up to the plugin to tell if it can support ramping or not (again, for some filters it's just not possible, except when rendering maybe). So I'd prefer to have a stream of events, each event being a *key* one, the ramping being optional, rather than an arbitrary stream of events, with no knowledge of which ones are the most important.

So a parameters stream at the same samplerate of the signal is the best.. only ideally. In practice it's a huge waste. Yes, even in a couple of years. And a stream would allow such a feature anyway, you'd just have a parameter change timestamped for each sample. Would make sense at rendering time.





--- Ron Kuper <RonKuper@xxxxxxxxxxxx> wrote:

>>>
BTW2 "We have always done it like this" is no
argument. "It works fine now so why change it?"
isn't
either.
<<<

Users have an investment in gear that works this
way.  Shipping
applications have an investment in architectures
that work this way.


Gear that users allready have doesn't conform to GMPI
now does it? Shipping applications do neither. In
fact, I wouldn't expect anything seriously GMPI before
2007 and then I'm being optimistic. Since GMPI will be
for new gear, you might as well add some new things.


Maybe it would help if you could provide a
real-world usage case where
using events causes a bad user experience?


I am not talking about bad user experiences of today,
I am thinking about improving and adding new user
experiences. The first fish that crawled out of the
see could only crawl but it was quite happy with that.
Still we would never want to go back to crawling again
(at least not me).

Defining controls as generators and treating them that
way allows you to modulate anything from any source
without introducing a new class of plugins (event
generators). Today, this is simply impossible. The
built-in LFO of your favorite sampler only does sines
or won't go high enough? Roll your own or use some
other synth for it. Your synth's ADSR doesn't provide
a chaotic attack? Roll your own. Etc.. If you've ever
played with modular hardware synths then you know that
you can create very exciting sounds through
modulation, especially "high" frequency modulation of
unexpected parameters from unexpected sources.
Furthermore, you could use only the modules you really
need instead of firing up a shitload of plugins that
all can do chorus. You might even gain some processing
power that way.

Turn your entire DAW in a hyper modular synth,
wouldn't that be cool? Use your imagination.

You could do all this by introducing event generator
plugins, but then you limit the upper frequency, which
is too bad. And you'd have a new class of gear, which
has to be treated differently, etc..

But as Tim kindly pointed out, this isn't the place
for discussing a standard that proposes exciting new
things as I was mistakenly thinking, you are
developing a standard for things that allready work.

Say, what if we all put the steering wheel at the left
side of the car?

Bye.
Crudesoft

P.S. When I said "random" I actualy meant "arbitrary",
I looked it up. Sorry about any confusion caused, but
we're not all native english speakers.



__________________________________
Do you Yahoo!?
Send a seasonal email greeting and help others. Do good.
http://celebrity.mail.yahoo.com

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe




----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: