search

pac-dev / protoplug

Create audio plugins on-the-fly with LuaJIT.
Other
278 stars 36 forks source link

problems in the timing API #45

Closed steveschow closed 2 years ago

steveschow commented 2 years ago

I think I have found a few problems in the midi API regarding some of the timing aspects...perhaps there is something I am missing, please advise if so..but here are the couple of problems I am noting, which frankly makes LuaProtoPlug currently unsuitable for time based midi processing.

  1. plugin.positionInfo.ppqPosition is not what you say it is. This value, as near as I can see is a fractional beat number according to the host....there is nothing related to the host's PPQN ticks coded into that. We have no way to find out, either, what PPQN resolution the host might be using, but most hosts use PPQN only to dictate their GUI while midi events are stored internally using sample accurate values..which generally translate into either a number of samples...or as a fractional beat value. The name of this value is confusing and very unclear as to what it actually is, but I suspect it is a fractional beat value, which you should verify and either change the API name or document its true meaning, or both.

  2. We do not have any way to obtain any kind of time reference value for the start of the current process block. It seems we can obtain from the host what the current location is, using timeInSeconds or ppqPosition, but the actual start of the process block usually does not line up with the host's current time position. Meanwhile, each midi Event has a time stamp that is relative to the start of the process block. Therefore we cannot accurately determine the time position of each midi event relative to the song position pointer. This is demonstrated easily when the transport of the host is stopped...the midi events come in with many different time values..because it will depend on where the midi event came in relative to a process block (which is usually the audio buffer that is always running...but meanwhile timeInSeconds, timeInSamples and ppqPosition are not changing at all while the transport is stopped, which tells me they are not in any way synchronized with the process block start time. Really LuaProtoPlug should probably ensure that those values for the Host's song position pointer report the value at the start of the current process block...not some other value unrelated to process block. Anyway, this discrepancy makes LuaProtoPlug incapable of accurate time based midi processing as far as I can see. Unless there is something I am missing.

  3. timeInSamples is not returning a double value, it is returning cdata which I don't know what to do with it. Can't use it without more info.

steveschow commented 2 years ago

I have verified that the problems in point#2 above are the same in a different product (BlueCatAudio PlugNScript, so this may simply be that way it is when the transport is not playing.

Point#3 I figured out to use tonumber() around the cdata value returned from timeInSamples. This works fine.

Point #2 just needs better docs, closing this ticket