[gmpi] Re: Topic 6: Time representation

  • From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Sun, 11 May 2003 18:12:52 -0400 (EDT)

On Mon, 12 May 2003, Vincent Burel wrote:

> -1- to timestamp an event , you need a time. So (ecxept if the host itself
> is managing the sequence) where to get a precise time related to audio
> stream on PC when using large buffer ?

So you're proposing we limit the plugin architecture based on presumed
limitations of today's hardware? Also "except if the host itself is
managing the sequence" applies to probably 80% of the work done with MIDI
and other events on DAWs.

> -2- to timestamp events precisely, all the Real Time event will have to be
> in a higher priority than the audio stream. This is simply not reliable
> under Windows at least.

Perhaps this is true for current hardware (forgetting, for a moment, MIDI
driver architectures with hardware-assisted timestamping) for real time
input events. However that's no reason to limit it for every other type of
event input.

> Once upon a time, one of my client tried Cubase, check the input gain of the
> AD converter on the VST mixer, and run a 8 tracks recording. Great ! it was
> working. After he played the 8 tracks !
(snip)
> So my client put the
> software in the trash and bought something else, and of course didn't buy me
> VST plug-ins...

Frankly it sums up your attitude that you or your client are prepared to
trash a $500 software package on the basis of something as minor as that.
From my point of view there are rather more important differences between
the major DAW platforms than whether their metering is free of annoying
buglets.

> -1- The host has to be stable (otherwise people does not buy plug-in, they
> just wait for the update of their crapy host)

True.

> -2- The plug-in architecture has to be simple and reliable, because if it
> takes me 1 month to port a plug-in, then i lose money.

Yes, but it also has to provide functionality. Otherwise why bother with
VST2 or DXi over VST and DX? There is still a need for functionality.

> -3- The both host and plug-in has to work perfectly together otherwise i get
> client on the phone and i lose time.

True.

> So , that i see with the timestamp concept , which is absolutely not
> according to the audiostation evolution (smaller and smaller buffer), and
> which is a technologie nearly impossible for the host to manage in real time
> under Windows like O/S.

Not true in 80%+ of cases, where the host is controlling the timing.

> i thought that GMPI was here to solve my problem of production, my problem
> of reliability , and in a way,  some problem related to the host exotic
> programming way.

It is here to do that, but not at the expense of throwing out
functionality (and, yes, complexity) that many of us need in order to
implement our plug-ins and hosts effectively.

> just an example : the GMPI group did start directly to design a new
> architecture of plug-in . without asking before what are the current problem
> in plug-in production, in plug-in management, in plug-in hosting. So which
> problem we are going to solve  in fact ? Again a typical programmer behavior
> : bring a solution without having a list of problems to solve.

This is not a design, but an open discussion... we are discussing problems
and their solutions under each of the different topics on the agenda. So
by the time this discussion phase is complete - which is still BEFORE the
real design work happens - we will have a comprehensive list of problems
and proposed solutions.

Regards,
        Angus.


----------------------------------------------------------------------
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: