Re: [linux-audio-dev] PTAF link and comments

Late reply, I was quite busy and english writing takes me time. I commented various people quotes here. However I haven't read recent posts yet, I'm a bit overhelmed by the reply avalanche. :) Yes the factory feature was also made for this concept. Many plug-in standards require instanciation before fetching properties. PTAF must be able to make good wrappers for existing plug-ins, industry requires it. We can also add somewhere a watchdog limiting the recursion. As suggested we can call it "host", or "main" thread. In my opinion generic forms of hosts have several "virtual" threads : - Audio: handles audio processing and related sequencing - Main/Background: handles generic operations, state transitions, as well as background disk streaming, data preparing for audio thread, etc. - GUI thread (at least on Win and Mac OSs), can theoretically be merged with the main thread, but it's not recommended (Mac programmers have the bad habit to poll the mouse within a blocking loop when user is holds a click). Ahhh I feared that. Yeah, I had this in mind when i was talking about lauching the GUI from the plug-in. But the token system is just about the same concept, isn't it ? For a given parameter, there is at most one active client at a time, others are passive and receive only change notifications. Arbitration is done by host, who is allowed to deprive a client from his token to give it to a client requesting it. For example it makes sense to give less priority to the automation system than to user via GUI, so the latter can steal its token, just by requesting it. When user has released the knob, it give back the token to the host making it available for any use (can transmits it implicitly to the automation system). Good point. Anyway I would like to minimize the number of functions. Functions are handy when the calling conventions of both parts are compatible. If the language you use doesn't support this convention natively, all functions have to be wrapped, which is a real pain. More, there are still issues with existing plug-ins, reporting wrongly if they support some opcode or not (talk to this issue to Plogue people :). The separation between coarse/fine grained plug-ins was just a design goal for the API. Fine grained plug-ins would have more issues, like the ability to do fast sample-per-sample processing (for feedback loops). Seems OK for me. Good, but it requires the host to be updated when new hardware is released. We can add a host property indicating the current alignment so the plug-in can check it before continuing. Professional musicians and studios have recent hardware, at least it's what survey results show us. Recent audio software produced by the industry also tend to be hungry, requiring fast hardware - I don't say it's good, it's just a fact, and industry is the main target for PTAF. If you plan to make a standard, it's better to build it for having use over years. After all, MIDI is still here and will probably last 20 years again. OK things are a bit different with pure software protocols, but arguing little performance boost against obvious programming safety is pointless for me (sadly programmer's brain doesn't follows the Moore law). Yes, but given my experience with customer support, unsafty displeasure is one or two orders of magnitude above efficency pleasure. The advantage of events is that you can have several of them at once, giving the plug-in the possibility to optimise operations. Dunno if this factorisation is really good. Different goals, different states for call, it should be a different opcode/func. Don't mix up audio configuration (which is not real-time) and connections. In most of cases I see, (de)connections is reflected in the plug-in by changing a flag or a variable, making the processing a bit different. For example a plug-in has a 2-in/2-out configuration. When only one input or output channel is connected, it gives the ability to make the processing mono, or to (de)activate vu-meters, etc. Right. Actually your solution is fine, efficient and simple :) Nothing. I even prefer that. That's why Base Pitch is float. But because MIDI is still there, existing plug-ins will be happy to round (after scaling if 1/oct) Base Pitch to get the note number. VST has also a finetuning delivered with each Note On. Absolutely. However many (hard/soft) synth can be tuned this way. It is a convenient way to play exotic scales using traditional keyboard, piano roll or other editors / performance devices. To make 1.0 the middle, default position. No, it makes sense for true bipolar data, but here 0 or close to 0 values have their meaning for parameters like velocity. It's not exactly like the volume. But how do you know on which bar the plug-in is ? Tempo and time signature can change in the course of the song and it is not obvious to deduce the song position from just an absolute time reference or a number of ticks or beats. For reasons mentioned above, both time in second an musical representation are needed. SMPTE etc can be deduce from the absolute time in seconds or samples. But is that so important ? Float or int, we manipulate numbers with a finite precision. And if someone is happy with tick scales multiple of 3, someone else will complain about not supporting multiples of 19, etc. For the drifting question, it is neglictible with double, and can be easily resync'd if required. Ohm Force's plug-ins use double as positions and steps for the LFO phases and it works fine without resync during hours, on any fraction of beat. If you need exact subdivisions, you can still convert the floating point value into the nearest integer tick. No it just would store and manipulate normalized values. Natural values would be needed only for parameter connection between plug-ins, if user chooses to connect natural values. They often require a variable amount of memory, making them difficult to manage in the real-time thread. However there is a need for this kind of stuff for sure. I thought more about encapsulating them into specific events. I agree with 1) and 4). For my experience, when a plug-in has 4), it has also 1), but it's not *always* the case because developers don't feel necessary to implement the hints correctly (dev time matters). Adding more UI description is likely not to be supported by either host or plug-in, making them useless. Good solution would be using portable UI libs, as someone suggested here, but everyone knows it's the Holy Grail. The only way to guarantee real portability through platforms and programming languages is to describe the API at the byte level. This include calling convention. IMHO We can assume that every target system has a stack, and can pass parameters on it. Well there are many different languages in the world and ASCII character set is good for US people but doesn't make sense for Japanese, Korean, Indian, Chinese, Arabic, etc. It is also limited for many European languages (loss of accents or character decorations). If you want to generate only ASCII in your program, just write only ASCII, it will be supported by UTF-8. However if you have to read strings, it's better to be aware that it's UTF-8, because incoming strings may contain multi-byte characters. It's not a big overhead if done efficiently. VST works this way for years, and people don't complain about this side at all. Host just needs to store and pass normalized parameter, so overhead is not here. It makes even things way simpler because data is alawys [0;1]/float, which wouldn't be the case with natural or multi-type parameter handling. On the plug-in side, overhead depends just on the conversion formula, and it's possible to make it very fast (segmented polynomial mapping for example). -- Laurent ==================================+======================== Laurent de Soras | Ohm Force DSP developer & Software designer | Digital Audio Software mailto:laurent@ohmforce.com | http://www.ohmforce.com ==================================+========================