On Wed, 2007-11-28 at 01:05 +0100, Marc-Olivier Barre wrote: I try :) -DR-

Dave Robillard wrote: Which doesn't mean we need to waste CPU cycles on comparing URIs in event processing loop :) I already gave you one example how it can be handled beyond what SysEx offers (by using interfaces). And another (by binding command numbers to URIs, preferably on plugin load). Read my previous mail more carefully. By the way, how old is IP? It is old, it is crufty, still, it won with competing protocols for some reasons :) Don't tell me you haven't heard about alignment. Please. Basically, the "useless" fields serve as padding when they aren't used. You'd have to have them there anyway, just as "reserved". Optimization often introduces cruftiness. If you looked at IP header, it's full of nasty, unelegant stuff. It also serves its purpose pretty well. Are you sure you are solving right problems here? Look at what purpose is it meant to serve. The difference is that ports are usually connected once per plugin load, or once per playback on/off, or comparably often. Not several times per 256-sample period. I've already said why it is more efficient. Please give statements that refer to details, not just vague "make no sense". For example, tell me why reading more data from DRAM to cache has no impact on performance in your opinion. I think we make a serious mistake of not trying to sketch out some code for reading a buffer, writing a buffer, handling binary data etc. I should be avoided, but not at cost of efficiency. But, preferably, it would not _mandate_ wasting CPU cycles. It should promote good programming. That's a good argument... almost. But there are counterarguments: - whenever you add more layers, you decrease efficiency - complexity of TCP protocol favours making it a separate layer, we don't have this level of complexity in our event types You didn't make it possible for the MIDI data to follow the event directly (well, you could say that if data pointer is equal to the first byte after event header, then size+padding should be added to header pointer, but that would decrease the elegance of your proposal). Also, as I said, you always use 16 (or 24) octets+payload length for every trivial event like MIDI. That's what I wanted to avoid. Oh, we have 1980 SysEx right here in your proposal :) Basically, that's the same thing you criticize me for doing. Let's do something better. As I said, you didn't even provide any way to transfer the ownership of the buffer to the plugin, so that it doesn't have to copy it. Generic events is one of the goals. Not the only one. Another goal, as I said, is not wasting speed (by wasting CPU-DRAM bandwidth, causing unnecessary cache thrashing etc), at least in the "expected" case. Another goal, is not wasting memory, but that's a low priority one - unless we're wasting speed by wasting memory. Well, please explain when do you need a random event access - I didn't factor it in during designing my solution, because, frankly, it's rarely, if ever, used in practice. You can always traverse the buffer first and make fixed-length index for binary search, if you really need random access. You're free to favour those unusual cases and degrade performance for everyone else, but do you really want to? Okay, that's a good start. What do you propose? Only if you ignore the remark about plugin declaring that its understanding of command 0x73 maps to uri http://blah.blah/mpeg2-video. Then the host will fill the command field with 0x73 whenever it needs to send the mpeg2-video data type. It's more work during plugin load, but then the plugin doesn't need to strcmp any uris or anything stupid like that in the audio processing loop - just compare command with 0x73. There is no central authority here, everything can be done in "spirit of LV2" with URI-based mappings. I was aware of the central authority problem, and as you see, it got solved. Right in the first paragraph of the second mail. No doubt. Relying on people to handle that is asking for trouble, especially if they have to work for free. Plus ego, differing visions etc. all contribute to problems. Preserve extensibility - yes. But do it in a reasonable way, taking care of more factors than just extensibility. Anyway... Let's try to LV2ize my proposal, just as some starting point: struct LV2_EVENT_HEADER { uint32_t timestamp; // timestamp uint8_t event_type; // event type number uint8_t args[3]; // short-form arguments or padding }; Event types are defined by the plugin like this: @prefix ep: <http://foltman.com/lv2/ep> . <http://someevent> ep:eventType [ ep:eventNumber 128 ; ep:eventName "CH1:Note off" ; ep:eventData ep:shortData ; ep:eventContent "http://www.midi.org/about-midi/specshome.shtml#ch1-noteoff" ; ]. (it's probably full of syntax errors, but at least you'll get the meaning if you try) Where: ep:shortData means that command arguments are contained entirely within args array ep:mediumData means that the 8-octet block follows the event header ep:longData means that the 8-octet block containing the IDataBuffer-derived pointer follows (where IDataBuffer would be something more or less like my LV2_BINARY_BUFFER proposal, with serialization added, perhaps); this is to ensure that we can pass structures with pointers, allow zero-copy approach etc. What exactly _is_ in those data (the semantics, as opposed to just data size and format) is dependent on eventContent. With longData, eventContent describes a specific interface (the only requirement is that it derives from IDataBuffer, so that it can be serialized, acquired etc easily). The host is responsible for sending right event numbers as required by the plugin (so the plugin might wish the channel 1 note off command be delivered as type 0, while http://foltman.com/lv2/ep#song-lyrics would be delivered as type 1). Of course, every sane plugin on the planet will just map usual MIDI command URIs to their usual numbers, but it won't be mandatory. You can also decide to drop support for commands like polyphonic aftertouch, and have some other types of events in the same range of numbers. This is kind of silly (extensibility gone crazy), but you kind of asked for it :) It has all the extensibility you wished for, and the (hypothetical) plugin code looks pretty straightforward to me. It is also pretty tight memory-wise. You (as a plugin author) can have commands with 3-byte data, 11-byte data, interface pointers - with whatever meaning you attach to them. The host would have to have each event types for each plugin easy accessible, but that's inevitable in any approach that doesn't use fixed number assignments. Now, what do you think? I think you might like it, because it's very similar to your "generic event" structure, just with more compact memory layout, and with zero-copy approach to large data. The MIDI-oriented folks might like the fact that they can pass MIDI data without that separate block of memory, while the rest can still do their advanced stuff with relative ease (using mediumData and longData). Again, that's just a starting point. Regards, Krzysztof

Lars Luthman wrote: 256 types is more than enough, in my opinion. Especially if MIDI takes just 1 type, not 128 :) How does the host know if the buffer has or has not been acquired (owned) by the plugin? With my approach, a plugin can either ignore data completely, or copy it into safe place, or increase reference count so that host doesn't free it until plugin has finished with it. It surely is a potential problem. While remapping can be really trivial, it's not efficient and perhaps should be avoided. On the other hand, how often do we send exactly the *same* event buffer to different plugins (think Set Parameter messages!)? Is that a typical or untypical case? What are example scenarios where that problem might arise? But, if we put whole MIDI stuff into a single event type, I'm fine with host-assigned numbers (which would be given to plugin on instantiation). Actually, a correct behaviour for the host would be to ignore the fact that plugin handles some events that host doesn't. The fact that plugin supports - say - video, doesn't mean that host must have anything to do with that video. It's a bit different if we're talking abot plugin's _output_ buffer here, but I guess there can be a way to make a plugin not send unwanted event types. Or to skip unrecognized event types. We might. But then we lose generality and reserve a huge block of event identifiers for an outdated crappy standard ;) Who uses polyphonic aftertouch these days, anyway? :) I thought of, at least, type ranges (like, 0x80-0x8F is note off ch1..ch16). That might reduce RDF bloat, but don't know what others will think about it. Anyway, single event type for MIDI is OK for me. Losing those 2 bytes on 1-byte events is really acceptable to me :) We need padding anyway, don't we? To clarify the issue: shortData means that the event data may be up to 3 bytes long, not that it must be 3 bytes. In case it's less than 3 bytes, the remaining bytes are used for padding/alignment. But, anyway, the shortData/mediumData thing in my proposal could have been done in a much better way (see below!). A small modification: what about struct LV2_EVENT_HEADER { uint32_t timestamp; uint16_t size; uint16_t event_type; union { uint8_t data[8]; float dataf[2]; int32_t datai[2]; IDataBuffer *ptr; } }; We don't need >65535 bytes for size, because copying THAT large blocks in processing thread (no matter if host or plugin does it) is a bad idea, just pass a pointer/object! 8 bytes of data is better than 7 bytes, because you can fit a 64-bit pointer there (on 64-bit machines). Or an int32_t and a float ("set parameter" event). I'm *slightly* against the size field, because it is another value that must be inspected in event processing loop, even with trivial events like MIDI. But it's not worth arguing, I'm fine with keeping size there. 12 bytes to inspect+4 to skip for average MIDI event is already slightly better than Dave's 16 bytes + 3 bytes "on the side". And memory management gets easier. Everybody wins :) So you've basically improved the "mediumData" thing and merged it with "smallData", by introducing size field. I think you are right. The only other choice I've considered was to get the size information from specific event_type (ie. if event_type == midi, then the plugin can assume that size == 0 extra blocks, etc, if it's float_parameter, then the plugin assumes size == 1, and the size for each event type is defined in RDF). But, comparing to that, keeping size in header is much better from debugging perspective etc. No, if we want to store pointers in single blocks on 64-bit platform. And I think we want that, right? :) I don't think it's a serious problem. Huge processing buffers are not very useful in practice. Having to call a function 10 times a second instead of 1 time a second rarely makes a difference. Again, it would harm the most common use case (realtime, low-latency audio processing) to slightly benefit a rare use case (non-realtime or high-latency processing, like song playback), so not worth it in my opinion. Thanks for all the comments and improvements, Krzysztof

Lars Luthman wrote: Well, making the common part common (for all "large" events) doesn't hurt. And it can potentially make stuff easier for transparent bridging over the network (when each "large" type implements an interface for serialization/deserialization). Again, the problem is perhaps that I just outlined the "large events/interface pointer" idea and didn't present it fully. I don't understand how. Maybe there's some misunderstanding about the event kinds. After your change, we basically have two event representations, "small" (say, ep:shortData) and "large" (ep:longData). - "small" events (<65536 bytes), where the content is stored directly in the header (first 8 bytes of content) and following bytes, if necessary - "large" events (arbitrary size), which are practically object pointers; they're passed by reference (to IDataBuffer-derived interfaces) The only interaction you'll have with "large" events will be: - when you'll have to make specific use of them (where you just cast the pointer to some IYourInterface pointer and call functions on that pointer), like in case of video processing plugin - when you're creating a network "bridge" plugin-host pair and have to pass these events over the network (that's where you use the hypothetical IDataBuffer interface's hypothetical serialization functions). Serialization is necessary because "large" events can potentially refer to some "foreign" objects, like handles to OpenGL textures in video memory and what not :) You cannot assume that all of your "large" event data will be conveniently placed in a single contiguous buffer in RAM, because it might not be the most practical way of dealing with them. If your data can be placed in a single contiguous buffer and there's not much harm (or use) in copying it, "small" events are the way to go. If you get the "large" event you can't use (because you don't handle the specific event type), just skip the event (just as with "small" events). It won't hurt and won't complicate the transport :) The same code skips both "small" and "large" events of unrecognized type. The only potential problem is what happens when the plugin returns an object ("large" event) to the host in an output event buffer, and host ignores it - but then, we could specify that host must explicitly call "decrease refcount" function on every "large" event received from the plugin, known or unknown, to avoid memory leaks. This is only a slight inconvenience for host authors, and besides, plugins shouldn't return unknown (not agreed by the host) events anyway :) Yes. Right. That's a good argument - filtering plugin list so that plugins that are useless in a given context (because of required events) aren't displayed. Well, it *is* done that way, isn't it? It is used only for "large" events, so it is implemented separately in the event types that need it! :) In other words, "large" event is the "small" event with additional clarification that the content is the interface pointer. We could even call those events, "data" instead of "small", and "object pointer" instead of "large". Again, a specific event type either declare themselves as "data" or as "object pointer". So, MIDI and Set Parameter event types would be "data", video, waveform and OpenGL geometry event types would be "object pointers". I also think events-as-objects have quite a lot of potential when it comes to, say, host-plugin or inter-plugin interactions :) I totally agree, it feels slightly ugly and odd, but I would keep it like that. I see three remedies: - expanding the structure (slow!) - changing bit ratios for i:f parts (which makes access to specific parts harder, and will cause complaints from subsample nazis ;) ) - or introducing a "65536 samples milestone" kind of event similar to "clear" message in LZ compression format, separating events from different 65536-sample "eras" :) The third solution is relatively inexpensive - one extra event for 65536 samples - but I guess it could be added as a further extension, when it starts being a practical (and not just style-related) problem. If the plugin does not implement this extension, it cannot handle buffers of more than 65536 samples - and that should be perfectly fine in most cases. Hell, max buffer size in Buzz was 256 samples, pitiful by today's standards, and it was still quite efficient. Krzysztof

Lars Luthman wrote: I think that might work. But then, you can only pass object pointer events that are known to the recipient. Especially in plugin-to-host direction (because with host-to-plugins, the host can just decref any object used in an event after plugin's process function ends, no big deal). This assumption is acceptable, in my opinion. Advantages: - simpler and shorter specification - modularity Disadvantages: - you can't tell between an object pointer (which cannot be just copied over the network or between processes) and normal data (which can be copied freely); at least not using this specification alone As long as some additional specification for passing object pointers in events follows this specification (some day), I'm fine with it. There is also a possible middle ground - an event type declaration in rdf would say not just what URI it corresponds to, but also if it contains any "unsafe" data (like pointers, handles etc). Just to possibly prevent a hypothetical transparent network/interprocess bridge from trying to smuggle pointers between process boundaries, which could lead to unexplained crashes :) Good. So let's postpone that part for now, it will go into different extension(s). Krzysztof

On Wed, 2007-11-28 at 23:56 +0100, Lars Luthman wrote: = 0;

On Thu, 2007-11-29 at 05:59 +0200, Nedko Arnaudov wrote: It needs to know that for an output buffer. I'd prefer to just have one MIDI event type and pass the status bytes as part of the event data. That way you can have generic MIDI processors or channel filters or whatever without having to list every event type in the RDF file. --ll

On Thu, 2007-11-29 at 14:55 +0200, Nedko Arnaudov wrote: You could, but there isn't really much to gain from it. The host will want to keep track of the buffer capacity in some way so those 4 bytes have to go somewhere, and I think having the same variable mean different things for input and output buffers makes things more confusing. --ll

Nedko Arnaudov wrote: Honestly, I prefer to have unnecessary information which I need to ignore, than fields with context-dependent meaning. Context-dependent meaning is usually more "evil". Buffer header is not the place to squeeze bits. Krzysztof

On Thu, 2007-11-29 at 12:55 +0000, Krzysztof Foltman wrote: We will want that eventually, but it's officially Hard(TM) :) Dynamic URI<->int mapping is probably a good thing. Raises issues though - maybe an acceptable compromise is that the existing ones never change, but ones can be added? Really no reason an already designated number needs to change URIs that I can think of, just tack new ones on the end. -DR-

On Thu, 2007-11-29 at 13:25 +0100, Lars Luthman wrote: ++ Event extension should keep it hands out of event contents entirely. MIDI is already well-defined. -DR-

Lars Luthman wrote: A bridge can compare the architectures of the bridged machines, and refuse to continue if they're different. That kind of bridge could be written by a well trained chimpanzee and work for (perhaps) majority of cases. Of course, to work for *all* cases, the serialization would be needed. Also, if the buffer is "simple" (as in: no pointers or handles whatsoever), the serialization doesn't need to be implemented or invoked! :) I would argue for additional Event_Port_Buffer pointer, as in "next". This way, the host could allocate event buffers in (say) fixed-size chunks, and the buffer is too full, another is allocated and linked to previous one. What do you think? So we agree on that one. How will it fail? (how will the host be notified about failure?) Is there any way to communicate the reason for the failure to the user? Just asking. A NULL-terminated array is good. Looks good! index += (events[index].size + 15) >> 4; right? I guess, sometimes the event port isn't *required* to be connected? Depends on a plugin, I guess. MIDI arpeggiator will need event support, so will a synthesizer, but a reverb with MIDI support might do without the event port support. Krzysztof

On Thu, 2007-11-29 at 13:56 +0100, Lars Luthman wrote: ...except that if all event ports are lv2:connectionOptional the plugin should _not_ fail to instantiate. --ll

On Thu, 2007-11-29 at 13:23 +0000, Krzysztof Foltman wrote: I just don't like to add complexity to the port buffer struct. Sure, worrying about one extra pointer may seem silly, but it's yet another thing that the plugin needs to check. The simpler the better. A host doesn't necessarily have to allocate one fixed-size memory block for every plugin event port, it can use one large shared buffer and dole out portions of it to each input port in each period, changing the capacity for each port on the fly to fit as many events as it needs to write to that port in that period. It's not a perfect method but it might work in most cases. Because it isn't really a separate optional feature, it depends on whether 1) all event ports have the lv2:connectionOptional hint and 2) the host doesn't plan to connect to any of those ports. If there are event ports that are _not_ optional, then the URI map is definitely required and the plugin should fail to instantiate if it doesn't get one. In that case it might make sense to list the URI map feature as a lv2:requiredFeature, although a bit redundant. If all event ports are optional then the plugin should not fail to instantiate because it doesn't get a URI map, but if the host then connects an event port anyway and writes events to it the plugin will have no idea what to do with them. You _could_ list the URI map Feature in the RDF data (as an lv2:optionalFeature if all event ports are lv2:connectionOptional, as an lv2:requiredFeature if not). I suppose it's just a matter of taste. --ll

Krzysztof Foltman wrote: In other words, the host sets capacity to max, calls the plugin, and resets the capacity to size of data received. Krzysztof

Lars Luthman wrote: Judging from my Buzz experience, I *have* to assume that plugin writers aren't going to know what they're doing - like a certain plugin developer who couldn't get the basic pitch-to-Hz formula right for several years, and many others (myself included). But, unfortunately, there's little one can do to remedy that. You could draft the specs in such a way that nobody with IQ under 170 could write plugins (DirectShow, I'm looking at you ;) ), but then you'd end up with no plugins. Unless certain features will need passing "personalized" pointers to plugins (separate host's objects per plugin). And by the way - seems that the char array/union part creates more controversies than necessary. So we may get back to Dave's idea of payload being a zero-length array (no minimum length), and to 8 bytes of alignment instead of 16. If LV2_EVENT_HEADER is defined this way: struct LV2_EVENT_HEADER { uint32_t timestamp; // still wondering if fractional addresses should be a part of generic even transport spec, by the way uint16_t event_type; uint16_t size; // of payload, with space occupied rounded up to nearest 8 }; it's practically as convenient to use as the previous version, and may be preferable in some cases (when bit 3 in payload size is 0). Then we may define (as another extension, perhaps) a MIDI event like this: struct LV2_MIDI_EVENT { LV2_EVENT_HEADER hdr; // or use as a base class in C++ uint8_t command, arg1, arg2, subchannel; uint8_t padding[4]; }; Or maybe instead of dedicating one byte to subchannel we might allow dynamic arbitrary assignment of extra fields (host passes an offset-and-length-to-struct-uri mapping). Well, maybe not. Or other possibility (WARNING: bit squeezing paranoia ahead): struct LV2_EVENT_HEADER // 4 bytes :) { uint16_t timestamp; // no fractional timestamps here uint8_t event_type; // 256 events are enough for everybody uint8_t size; // 256 bytes are enough for everybody }; struct LV2_MIDI_EVENT { LV2_EVENT_HEADER hdr; // or use as a base class in C++ uint8_t command, arg1, arg2, padding; }; // separate event type for those 3 instruments with per-note control changes struct LV2_MIDI_EVENT_SUBCHANNEL { LV2_EVENT_HEADER hdr; // or use as a base class in C++ uint8_t command, arg1, arg2, subchannel; }; // separate event type for those 3 specific granular synthesis hosts and plugins struct LV2_MIDI_EVENT_FRACTIONAL { LV2_EVENT_HEADER hdr; // or use as a base class in C++ uint8_t command, arg1, arg2, subsample; }; (1/256 of a sample should be good enough for everybody, too!) Krzysztof

On Thu, 2007-11-29 at 19:43 +0000, Krzysztof Foltman wrote: ++ FWIW OSC (and by extension, my LV2 OSC stuff) does this too, except with 4 bytes instead of 8. I /really/ don't like screwing around with MIDI. Just make the events pure, raw MIDI. Jack MIDI events are 'just n bytes of MIDI', Alsa has functions to get at 'just n bytes of MIDI', and... well, it's just MIDI. Everyone knows MIDI, it's probably the most ubiquitous audio standard in existence. Keeping our hands out of it means trivial interoperability with everything: past, present, and future. We should just leave it be. It's working this way in Jack right now, it's working this way in LV2 right now. If it ain't broke.... -DR-

On Fri, 2007-11-30 at 00:30 +0000, Krzysztof Foltman wrote: Definitely. This is why event type agnostic event ports are a good thing. You're free to make a better MIDI if you want (I'd say use OSC and leave MIDI on the trash pile of computing history where it belongs, but that's just me), but the normal MIDI events need to be plain old MIDI. In short: don't rock the boat; all this Jack/LV2 MIDI stuff is still getting off the ground... No it isn't, it's extremely elegant. What's inelegant is cramming too much garbage into an extension when that garbage is a separate problem. You want to define a new event type? Define it! No consensus, no debates, no fuss, no muss. You can get the whole thing working and implement it in a host and plugins both before even telling anyone about it at all (if you want), and /nothing breaks/. Your plugins can even be run in another host that doesn't even know what the heck these events/ports even are, and everything will work fine (except, of course, those ports/events). If that's not elegant, I don't know what is ;) -DR-

On Fri, 2007-11-30 at 11:10 +0000, Krzysztof Foltman wrote: If you really think it would make a difference to compile a list of what people have in mind, go nuts. True, but these things are generally discussed on the list anyway (as they are right now). If that does happen, you can just make something better. Generally, host authors won't support things they think are stupid/short-sighted/whatever, so the problem takes care of itself for the most part. You speak as if these two things are different, somehow? :) The invisible hand of the scene created all this... Quite a bit of thought has gone into hypothetical extensions to make sure the core spec is sound, but the complete independence of extensions from the core spec is a fundamentally good thing. Everything LV2 should be tackled in terms of the smallest sub-problems possible (hence e.g. my oppositing to cramming event definitions into the generic event transport stuff). Read the archives of this list (or, even better, the GMPI one..) enough and it's pretty clear that's the only way we can actually get things done 'round here... and, hey, because of it we're getting things done around here right now. We have working plugins, MIDI, dynamic parameters, OSC, toolkit agnostic embeddable GUIs; we're soon getting generic extensible events, control ramps, message-based stuff.... GMPI has a few years worth of pointless bickering and arguing on a mailing list archive somewhere. QED. Love or hate all this "extensible" talk and RDF stuff, the proof is in the pudding. I love it when things work out. :) -DR-

On Sat, 2007-12-01 at 20:13 +0100, Lars Luthman wrote: Ah, right. I was debating even mentioning that bit :) Has the world beyond IRC seen your videos? You should post one for the list maybe.. -DR-

On Thu, 2007-11-29 at 09:19 +0000, Krzysztof Foltman wrote: Serialisation (be it for a network or to a file or whatever) is an event type specific thing; orthogonal problem. OSC, for example, precisely defines the binary format of a message for network transmission. New event type extensions can define such things on their own as well. -DR-

On Wed, 2007-11-28 at 17:19 +0100, Lars Luthman wrote: ++ Extensions should be kept as small and limited in scope as possible. "Do one thing, and do it well"... -DR-

On Wednesday 28 November 2007, Krzysztof Foltman wrote: [...] [...] Actually, they're directly harmful most of the time! For any graph with more than one plugin, and with plugins that use internal buffers of the I/O buffer size, large buffers means you'll get a gigantic cache footprint. It gets worse in "high" latency real time situations (games, media players etc), where you have other threads fighting for the cache as well. Obviously, this effect is less visible with non-trivial plugins - but even how many plugins in a "normal" graph are actually CPU bound? In my experience, the effect is very pronounced (several times higher CPU load with 512 samples/buffer than with 32) when using a bunch of sampleplayer voices (cubic interpolation + oversampling) and some simple effects. You have to do some pretty serious processing to go CPU bound on a modern PC... //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Wednesday 28 November 2007, Dave Robillard wrote: [...] I did, and that's what I'm drawing my conclusions from. ;-) No cache controller logic in the world can avoid the bottleneck that is memory bandwidth. If your data has been kicked from the cache, it needs to get back in, and the only time you're not taking a hit from that is when you're doing sequential access *and* your code is CPU bound, rather than memory bound. Right, that's not the issue here, but I'm talking about "cold" memory and raw bandwidth. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Thursday 29 November 2007, Dave Robillard wrote: [...] [...] Of course, but that's exactly what I'm talking about - large buffers, and why it doesn't make sense to support them. :-) If you're using 65536 samples per buffer, it just takes a plugin with four audio inputs and you're up to 1 MB of intermediate buffers. Even if that does fit in the cache, in a real life situation, with other threads working, most of it will be cold again every time the audio thread starts. So, your processing speed is potentially capped at the memory bandwidth throughout the buffer cycle, or at least until you start reusing buffers in the graph. And what is supposed to be gained by this...? I don't see why a plugin API of this type should support nonsense like that at all, and thus, it shouldn't affect event timestamps either - but well, now it's there, and there isn't really any Right Thing(TM) to do here, I guess. Last time I looked into this, a reasonably optimized resampler with cubic interpolation and some ramped parameters was memory bound even on a lowly P-III CPU, at least with integer processing. (Haven't actually tested this on my AMD64...) I think floating point should be as fast or faster in most cases, at least on P-III CPUs and better - and with SIMD, you may get another 2x-4x higher throughput at that. Could be way off here, though. Do you have benchmark figures? //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Friday 30 November 2007, Dave Robillard wrote: [...] Yes, that's exactly what I mean. Sure, one *could* have a use for really huge buffers (say, running large FFTs without intermediate buffering), but to me, that seems too far out that one should have everyone deal with 32:32 event timestamps for that reason alone. [...cache footprint, buffers etc...] I'm assuming any serious host implementation does that, but that doesn't help when some plugins are using more than 1-2 audio inputs. Even so, it shouldn't really be an issue unless huge buffers - like //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Friday 30 November 2007, Dave Robillard wrote: [...] Well, normally, you'd use the integer part for splitting the "sample loop" internally (that is, you need to calculate loop counts from it), and you'd use the fractional part alone to determine offset within the sample frame. Might be hard to avoid the weak spot of modern CPUs that is FP<->integer conversions. I don't know if this is a real performance issue, though. Besides, you probably have to do some integer->FP conversions to make use of the fractional part of integer timestamps in FP DSP code - but then again, that impacts only the plugins that actually use it. Others just shift the fraction bits out and use the resulting integer sample frame offset. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Friday 30 November 2007, Krzysztof Foltman wrote: [...several points that I totally agree with...] That would seem to add complexity with little gain, though I haven't really thought hard about that... It seems more straightforward to just use sample frame offsets when sending; you just grab the loop counter/sample index. However, in the specific case of my "instant dispath" architechture, you'd need to look at the last event in the queue to calculate the delta - but then again, you need to touch that event anyway, to set the 'next' field... (Linked lists.) No showstopper issues either way, I think. When receiving, OTOH, deltas would be brilliant! You'd just process events until you get one with a non-zero delta - and then you process the number of sample frames indicated by that delta. (Obviously, end-of-buffer stop condition must be dealt with somewhere. Adding a dummy "stop" event scheduled for right after the buffer would eliminate the per-audio-fragment check for "fragment_frames > remaining_buffer_frames".) That's another idea I might steal! ;-) I'm not sure, but it seems that you'd normally not want to drive a sub-sample timestamped input from an integer timestamped output or vice versa. An output intended for generating grain timing would be concerned about generating events at the exact right times, whereas a normal control output would be value oriented. This may not seem to matter much at first, but it makes all the difference in the world if you consider event processors. With pure values, you might want to add extra events or even regenerate the signal completely, but this would break down when controlling something that relies on event timing. Might be worth considering even in non modular synth environments, as you might want to edit these events with in sequencer. This is starting to sound like highly experimental stuff, though. :-) I'd want to try actually implementing some different, sensible plugins using this before I really decide what makes sense and what doesn't. Granular synthesis is about the only application I can think of right now that *really* needs sub-sample accurate timing, so that's the scenario I'm considering, obviously - along with all the normal code that doesn't need or want to mess with anything below sample frames. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Fri, 2007-11-30 at 09:45 +0000, Krzysztof Foltman wrote: The "Fixed point is faster than FP" thing is a myth that shows up here and there and is usually taken as gospel by people who don't know what they're doing (or what their CPU is doing) ;) Fixed point is a PITA. Time based effects and whatnot do math on time stamps, and doing math on fixed point is a massive nuisance compared to floating. With floating, if you want to time stretch by a factor of 2.... multiply by 2. Fixed? Well, first write your fixed point arithmetic library, then......... Unless there's very /significant/ advantages to bothering with it, well.. why bother with it. I've advocated high precision floating point in the past because 'groove' effects and such are obviously much better off with such a representation. At the end of the day, for basic synths etc. timestamp things aren't going to be a remotely significant part of the CPU time spent by a plugin; I doubt the fixed point nuisance is worth it. Premature optimisation is the root of all evil... -DR-

On Wednesday 28 November 2007, Dave Robillard wrote: [...] I don't know if this is applicable here, but for Audiality 2 I'm dealing with this on the connection level. Each control is a port like any other, meaning it has a name, a protocol URI and a few other parameters that the host needs to know what can and cannot be connected. If two ports have the same URI, they can be connected, and that's it, basically. Event semantics ("structured stream", "commands" etc) and data fields are left to the plugins that implement the ports, so the host doesn't even need to know what the plugins are talking about. (This is a "direct connection" model; data is not normally piped through the host.) On the physical level, I still have ports share event buffers (or rather, queues in this case) so plugins don't have to sort/merge or poll umpteen queues all the time. "What event goes where" is decided by means of filling an address field with an opaque cookie value that the plugin generates upon connection. The cookie can be ignored if there's one queue per port, or it can be a fully specified plugin-wide port index if the plugin uses a single event queue, or anything in between. Multiple queues...? Yes, A2 plugins can use multiple queues when that suits the implementation better. (Multiple inner loops, rather than running the whole synth, all voices, or whatever, one sample at a time.) Thus, a plugin doesn't have to mess around with the events to get them to the right places in the right order. It just creates one queue per voice/strip/section/whatever loop and hands the right queues out when connections are made. This means an "event target" also needs to contain a queue pointer. Of course, one could just use one queue per plugin and use only cookie addressing, but I decided to allow multiple queues to eliminate most of the event dispatching complexity you'll otherwise have in any non-trivial plugin. It seems to be a simple and efficient solution, but I could be missing something, of course. Remains to see when I have some more serious code running. :-) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Wed, 2007-11-28 at 19:07 -0500, Dave Robillard wrote: I am coming horribly late to this discussion, so I might be being thick, but what happens if each event contains a pointer to a C style string being the URI... Bloated and slow right? Now here is the trick, we convert that to a unique identifier at run time by registering each unique event URI as a string in some data structure (Map, linked list of parameters, whatever), then at event creation time we set the pointer to point to our single common instance of the URI. Now all events of a given type have the same value stored in that pointer which will serve as a unique ID for this event for run of the programme. If saving event data to disk, we just replace the pointer with the string it pointed to. struct event_t { char * uri; size_t data_length; char data[1] }; On loading a set of events build a list of every unique uri and patch each events uri pointer to point to it. struct known_events { char *uri; int (*handler)(struct event_t * ev, void *param); struct known_events *next; } Or something like that. Now using the fact that the address of a struct is the address of the first element of the struct, running an event is simply ((struct known_events *) event.uri)->handler (event,whatever); Or something like that, I didn't try to compile it. If we wish to check if two events are of the same type then if ((char*) event1.uri == (char*) event2.uri){ is sufficient and is a single 32 or 64 bit integer comparison. Just a thought. Regards, Dan.

Dan Mills &lt;dmills(a)exponent.myzen.co.uk&gt; writes: I somewhat like the idea, but how would this work for a host dispatching opaque/unknown events? Maybe such host would load plugin event type uris From RDF and just use them in opaque way. However, I dont see benefits over the uri-map approach proposed in the other subthread. using uri map indexes looks quite more cleaner and intuitive to me than assuming uri pointers are constant. IMHO later can be quite confisung for not that experienced plugin writters. I don't get why this handler callback is needed at all. In LV2 such events are supposed to be processed during run(). It is worth to discuss how host dispatching opaque events will notify already instantiated plugins about new event type introduced by loading new plugin. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

Dave Robillard wrote: That's right. Lars addressed that criticism pretty well, I think. The "evolved" proposal is both keeping headers and data in the same place and keeping event semantics on separate layer from event transport. Here it comes: char* buf; ///< raw event data Maybe you meant to write this? char buf[]; ///< raw event data directly follow here Because char* usually means, you know, a pointer, not a variable length array :) Take this, and solve alignment and URI numbering issues, and both proposals (LarsL&KF and yours) are actually the same one. Which is a good thing. Lars solved that one pretty well. Unless the handing out is done on the fly, based on URIs. Like, say, file descriptors :) We still have "central authority", but this time it's the host loading the plugins, not a person. Should give a much better roundtrip and less authority abuse ;) Krzysztof

Dave Robillard wrote: You *do* know C, yes? Well enough to judge others? Hint: try this little proggy (gcc should compile it fine): #include <stdio.h> int main(int argc, char *argv[]) { struct X { int a; char buf[]; }; struct Y { int a; char *buf; }; printf("%d %d\n", sizeof(struct X), sizeof(struct Y)); } /* Krzysztof */

Dave Robillard wrote: Sort it out with gcc, not with me :) And if you meant that event->buf is still a pointer, buf the value of event->buf will always be (&buf)+1, then we will always have a pointer dereference. Which is (slightly) less efficient and usually unnecessary. If you define a type that passes large data, put the pointer in payload, it will only have to be dereferenced for that particular event type. And if you meant that it's "usually (&buf)+1 but not if data is large" then we also need to check if we need to skip the (possibly non-existent) data block or not. As in: if (event->buf == (char *)(1 + &event->buf)) { // data are in-place, skip then event += some_function_of(event->size); } else { // data are somewhere else event += some_function_of(header_size); } In other words - just remove the pointer from the generic header, or replace it with buf[], a zero-length in-place array, as opposed to 4- or 8-byte pointer - and nobody's hurt ;) And by the way - maybe it would make sense to use some sort of performance testing framework to check which event headers are faster and how much impact does it really have? If the difference on a gain plugin (or say, wave playback - to test cache-intensive stuff) is within, say, 10%, with 256-sample buffers and event density of 8 samples/event, then there's not much to argue about. Krzysztof

Lars Luthman wrote: So, basically, we have a choice between: struct LV2_EVENT_HEADER_LLKF { uint32_t timestamp; // 16:16 uint16_t payload_size; uint16_t event_type; }; struct LV2_EVENT_TYPE_X { LV2_EVENT_HEADER_LLKF hdr; // type X-specific data here (be it a pointer, or in-place data, or whatever) // size must be an integer multiple of 8 bytes }; and different variants of: struct LV2_EVENT_HEADER_DR { float_or_double timestamp; some_int_type2 payload_size; some_int_type event_type; // pointer to data or inline data array here }; which - I believe - Dave seems to favour. Krzysztof

On Fri, 2007-11-30 at 16:21 +0200, Nedko Arnaudov wrote: Might as well break the time stamp into two separate uint16_t's and make life easy. Please, please let this silly 'type of the data member' angle of conversation die... :) Hereby humbly requesting that: // data follows here be the last thing in the event struct for the purposes of this conversation, since it's irrelevant and not a point of debate -DR-

On Fri, 2007-11-30 at 10:42 +0000, Krzysztof Foltman wrote: The struct does not actually exist, its sizeof is irrelevant. [snip] The data is at &buf. That's all. The sole significance of that struct member is that the data is at &buf. It doesn't matter in any way whatsoever what that struct member is. Honest. ;) Read the comment... the buffer format couldn't be more clear. -DR-

Krzysztof Foltman wrote: Oops, that should be: i += (event[i].size + 7) >> 3; :) Krzysztof

On Sat, 2007-12-01 at 14:56 -0500, Dave Robillard wrote: But the whole concept of time in an LV2 plugin is defined in terms of audio frames. The amount of time to process in each run() call is given by the host in number of frames - using frame offsets as event timestamps is clean and consistent. And it's not as if resolution is a problem, at 48kHz we get 318 ps resolution compared to 232 ps with OSC timetags. Those extra 86 picoseconds aren't going to cause any real problems. And I really like the 8 byte header + 8 byte aligned data. It's nice and simple. There is of course no reason that any event type that needed another time representation couldn't embed that in the event data, but for most purposes it would probably be easier to just have the host take care of any translation that's needed to e.g. send OSC events out to an UDP port. -ll

On Sat, 2007-12-01 at 21:49 +0100, David Olofson wrote: Obviously MIDI-like events to be handled in-band in the audio stream would use frame time stamps, yes. You can't do everything with in-band realtime events though... say, firing around video frames in events for processing (not at all unheard of in pd etc). You can't be doing complex image processing in the audio thread, that's idiotic. ie yes this is a wider scope for events, but it's necessary. I'd rather not go on this digression to be honest, multi-context plugins/patcher environments with events crossing contexts is not a trivial subject. The time stamps being up to the task would sure be nice though... All I ask for is a few measley bits :) That I can point to widely accepted standards (one of which is very, very close in domain to this event stuff) that use timestamps of this sort is telling.. Anyway, making the frames part 16 bits screws up parity with Jack MIDI. We already have a uint32_t frame timestamp. We want fractional, so stick a fractional part in there, voila. The host just sets the fractional part to 0 from Jack, things can use the fractional bit (or not) as they please. Simple. -DR-

On Sat, 2007-12-01 at 22:19 +0100, David Olofson wrote: Understandable. I'm thinking the events themselves can be the same (they're so open-ended, why not..) but the transport mechanism would just be different. Some kind of one-event-at-a-time thing instead of a big flat buffer. There's also the sharing of transport layer and 'crossing' contexts, yes. The way I see it in both cases the generic event is just a time stamp, size, and some data, so might as well make this one good enough. Precise timing resolution never hurt anyone anyway. Yep. Something ala: struct LV2Event { uint32_t frames; uint32_t subframes; foo_t type; uint32_t size; // data follows here }; Best choice for order and foo_t for alignment? Making it smaller than 32 makes size's (and data) alignment suck, but 2^32 types of events at one time is pretty nuts. Cheers, -DR-

Dave Robillard wrote: I think there's certain advantage to using sample frames for events in the typical audio plugin situations. On the other hand, it doesn't cover all weird stuff people will want to do. I could even think of two event ports - one for typical frame-based stuff, other for absolute nanosecond time or what not. Keep in mind that converting nanoseconds to frames in typical case would be very very slow (64-bit divisions, or at least multiplications) So, if we need something else than sample-based timing, we should do it elsewhere (by defining another event type, or something). Trying to fit everything in - audio, video, networking, industrial equipment, car engine control etc - is highly likely to fail. Also, huge overkill, in my opinion :) It might be needed in some cases, but demanding everyone to use this resolution is bad. You may not like it, but I would actually like two kinds of ports: - one for experimental weird stuff (may be even 64-bit integer in 200-picosecond units, why not); this could be nice for certain uses but overkill/inefficient in most situations - one for bread-and-butter stuff, sample based; and here you could even use just 32-bit integers, not fixed point numbers, the certain events that would indeed require fractional part of the timestamp (grain start), would define it as a part of payload The structures will probably be very similar, the event types carried inside might be the exactly same (including URI-to-number mapping scheme!). The experimental plugins and hosts would implement the extended event transport, most of the everyday stuff would just stick to the basic sample-based one. That kind of fits the "do one thing and do it well" rule. Both ports wouldn't be directly compatible anyway (because they use different timing schemes) so why not keep them separate? :) I'm more comfortable with 8-byte header, just because it lets us use headers as unit of data (payload is always padded to 8 bytes, think pointers on 64-bit machines). As in the code example I've posted (minus the bug). With 12-byte headers, we get some ugly pointer arithmetic (and pointer alignment problems on 64-bit machines). With 16-byte headers, we either count in 16-byte units (just think of 1-byte MIDI messages here :) ), or align to 8 and get ugly pointer arithmetic. You can't just write anything as brief as: i += (event[i].size + 7) >> 3; when you have 12-byte headers. And losing 15 bytes for 1 byte messages in 16-byte solution without pointer arithmetic may be acceptable, but gives me certain discomfort :) Yet another solution would be to keep header 12-byte + 4 bytes of data/padding (for short messages). But I think we've already been there, and you didn't like it much, right? :) Everything that allows plugin loops to be simple and readable and doesn't waste CPU/bus cycles or (whether on misalignment penalties, long divisions, float-to-int, 32 bytes per average event) is going to be fine to me. It's just that... well, you can see for yourself, there are not many solutions that satisfy all of those criteria. Those are my reasons for "bit paranoia" which annoys you so much :) Absolute time stamps can still be done by keeping some sort of state between process calls, plus optionally some "set absolute time (resync)" kind of events. Tastes like 64-bit division, which as far as I know involves a function call on average x86 platform ;) Good for some stuff (networking, audio plus video), absolutely horrible for others (think granular synthesis which has dense events). I like this - just don't like the consequences on header size :) Hard to find a clear winner here. By the way, what about 48-bit timestamp as another candidate? (32 int, 16 fract) Still leaves 2 bytes for other stuff (size, type) in 8-byte header. Restricting payload size to 255 bytes max doesn't sound like a total disaster. Larger data will be likely passed by reference anyway, doing otherwise in a realtime system usually smells like bad design :) Just think of memcpying those data back and forth when those 20 reverbs wait for their turn :) Krzysztof

Dave Robillard wrote: Just efficiency. 8 bytes instead of 16 for empty messages. 16 bytes instead of 32 for MIDI messages. Sounds less stupid than just "saving two bytes" as you picture it. And speaking about translation - of all the timing-related work required to translate between different event protocols (beat:tick, frame-based, picosecond-based), different bit layout is the least problem you'll be dealing with! :) Plus, for us C++ folks, it would probably be nicely solved with some sort of class template ;) Perhaps, if we go 64-bit (although I still think it's overkill!) it might make sense to make a timestamp a sort of an union, so some event types will use one int64_t member (say, 200 picosecond units) instead of integer+fractional? Just cosmetics. So we'd have something like: struct LV2_EVENT_HEADER { union { int64_t timestamp64; // for event streams that use one large number as timestamp, like OSC??? struct { int32_t timestamp; int32_t timestamp_fract; }; }; uint32_t type; // don't see any other choice but int, opaque pointer won't fit on x86-64, plus, index is all we need, given a good URI mapping mechanism uint32_t size; }; With 16-byte granularity for payload (ie. size is rounded up to nearest multiple of 16 to determine next header address). Or perhaps 8-byte, winning some memory at cost of messier code. Assuming the compiler and language used accepts anonymous structs and unions. Otherwise, too many dots ;) And that probably is what we need, it looks OKish for most intended uses. Not optimal for *all* uses, but good enough for my purposes, and the generic-efficient-easy tradeoff is OK to me. Using a small structure when a small structure is just fine. When you have lots of events, this may be very important. In other situations, no clear advantages of 8-byte struct over 16-byte. Well, let me try to rephrase it, because I sense a huge miscommunication here. When payload is always aligned to header size (8 bytes in my case), the loop can look just like this: for (size_t i = 0; i < count; i += (events[i].size+7) >> 3) { // use events[i] here, cast to event type struct if needed } or (events[i].size+15)>>4 with 16 byte header Short, simple, efficient. How would the same code look like if header was 12 bytes long? (assuming we want to guarantee 8 byte alignment for 64-bit pointers or int64_t values - I think it's important because, again, on some platforms, misaligned access = SIGBUS) I can only think of some ugly multiple pointer casting crap, can you give a clean example? Other than sweeping the ugliness under the carpet by closing the pointer arithmetic in some sort of standard macros :) We can always use 16 bytes, but then payload is 16 bytes too. Which is 15 bytes and not just 2 bytes wasted. Per (short) event. Some of those 15 bytes (if not all) will probably end up in cache anyway, because cache is not byte-addressable (I don't remember the addressing granularity, 32, 64 bytes?), and will be wasted. Again, not a huge deal, except people who do granular synthesis will probably curse me at this point. So we end up with two-three event stream types, each using different timing scheme. Not as bad as it sounds, certainly, because each of these types will be used for different things. What I proposed was to use different event structure layout for those event streams. As I said above, the differences between those streams are so huge, that translation between 8-byte and 16-byte headers will be the least of the problems :) 1. 16 bytes, not 4. Unless you want char * casting ugliness and misalignment problems. 2. When exactly does JACK use buffers of 65536 samples and more? Not very often, I guess. It's half a second or more of latency. Multiplied by number of buffers. 2 structs, not 5. And the translation will have to be there anyway, unless you expect sample-based plugins to read OSC-style timestamps. By saving 2 bytes, it saves 8-16 bytes. Magic, isn't it? :) Typically you need to memcpy it at least once, in host - the data must get into the flat buffer somehow, right? (data of this size aren't usually produced ad-hoc in-place?) The "JACK does it" is not a winning argument to me - the fact somebody arbitrarily picked int32_t (perhaps just because there's usually no point in passing parameters to functions which are less than 32 bits wide, because they get passed as 32 bits anyway, and using fields <32 bits in structures leads to alignment troubles) doesn't mean that you have to follow that choice. If you want to store OSC messages transparently, though, 32 bits would be nice. Krzysztof

Dave Robillard wrote: uint32_t *p = &some_int_array[0]; p += 7; Q: Where does p point now? A: 28 bytes ahead of its previous value. That's where the elegance-related problem lies (IMO). If the struct size is 16, and you want to increase the pointer by 8 bytes, you need to cast to char*, increase by 8, and cast back to LV2_EVENT_HEADER. That's what was (and is) bugging me. i += (events[i].size+7) >> 3; is a bit nicer than: p = (LV2_EVENT_HDR *)((char *)p + ((p->size + 7) &~7)); to me. Still, it's just one line of code, and can be put inside of a macro or something, so the messiness might be perfectly bearable. I might also keep the current pointer as char * for easy incrementing, and cast to LV2_EVENT_HEADER * (or whatever) when needed. Putting things in perspective, it's not even nearly as ugly as what goes on inside plugins' inner loops, so it might be perfectly acceptable ;) Krzysztof

I think the version you (probably) proposed is: struct LV2_EVENT_HDR { uint32_t frame, subframe; unsigned int size:24; unsigned int type:8; // put data here, but header size+data size must be a multiple of 8 }; plus 8-byte alignment requirement (ie. header size+payload size must be an integer multiple of 8), is going to work. Either that, or 16 bits for both size and type. Or 16 bits for size and 8 bits for type, and the remaining byte may be used for char field in payload (5 byte payload "for free"). All three are more or less equally good/bad. MIDI would look like this: 12 bytes header, (up to) 3 bytes content, 1 byte padding - which is fine. Same for pointer-only data on 32-bit architecture, for 64-bit, there would be a padding of 4 bytes followed by 8-byte pointer. Not very elegant, but perfectly acceptable. Plus, the compiler takes care of generating padding. Krzysztof

Dave Robillard wrote: I prefer 16+16 to 24+8. I can see more uses for 16-bit types than for 24-bit sizes (basically, defining a new URI for every parameter exposed by a plugin, you'll find people insane enough to try that). Perhaps you can probably see the applications where 24+8 is more desirable. Decide for yourself. Yes, I think so. 64-bit platforms are getting more and more popular. BTW, does reading a double from address misaligned by a dword involve performance penalty? If not, we can say that we use alignment of sizeof(void *) on a particular platform. Should be enough. Well, at some point we're going to end up with some structs anyway :) And it would be (slightly) better if whatever binary representation we agree will have a 1:1 C struct(s) counterpart, if you know what I mean. Even if finding the address of the next struct is going to require some pointer magic hidden in macros. I prefer to use event->whatever than EVENT_GET_WHATEVER(event), if possible :) In other words, we can define the buffer content in two ways: 1. By specifying offsets of particular fields (including payload fields for every event type) as numbers. We need to ensure that our platform-independent binary representation is really platform independent (ie. all payload types that contain pointers reserve 64 bits for them, otherwise they get unusable in 64-bit environments because pointer doesn't fit etc). 2. By defining it as C structures, and calculating offsets based on how platform's compiler lays these structures out (ie. if header is 12 bytes, then a pointer follows, then on 32-bit architectures it gets offset 12 and payload size is 4, but on 64-bit architectures it gets offset 16 and the payload size is 12: 4 bytes padding plus 8 bytes actual pointer). As you see, I clearly prefer the solution 2, because the main advantage of solution 1 (platform-independence of binary format) is not 100% ensured anyway, unless every single event type used will be platform-independent (and perhaps self-contained, ie. no pointers outside of the buffer, no handles to local resources, etc.). The platform-dependent binary layout of messages is not such an uncommon thing. In fact, platform independent binary layout of structures is usually used in network protocols, not APIs. What we're defining now is more related to an API than a network protocol, isn't it? ;) Krzysztof

Dave Robillard wrote: So, 16:16 it is. I've mentioned pointers. You don't see the use for storing pointers in payload? For SSE we'd need 128-bit alignment (4 floats). But I doubt our payload is going to be used for SSE and the likes. I'd be very surprised, actually. Well, usually APIs use pre-determined order, but not pre-determined sizes. ie. some fields are 32-bit on some platforms and 64-bit on other platforms, but the field ordering is always the same. Yes, but... I mean... we'll end up casting to a struct pointer, not cherry-pick individual fields via pointer operations like this: int size = *(int *)(buf + 4); That's what I was talking about. Accessing a _single_ struct as a struct. The "running" pointer will probably be char *, right, but for processing of a particular event, it will be cast to a struct pointer. What I was trying to say was "padding and field sizes - at least for some fields - should be platform-dependent". Not in header (because header works equally well on 32-bit and 64-bit). I don't want to vary field ordering on a per-platform basis either. That'd be a PITA. Just field sizes and alignment, and only when *really* needed, in payload. I hope you're OK with that. It's what other APIs do, for example, they may have a member of type 'size_t' in some structs, which is 32-bit on some platforms and 64-bit on others. Anyway - I suppose at this stage it's a human language-related problem, not major differences in opinion. So, solution number 1. Just look at solution number 2, it might be more attractive anyway, even if I wasn't able to convince you by myself. You probably need to spend some time trying out your own ideas with both solutions. Perhaps I should have given some examples too, I don't know. Yes, I got that. It's good and I want to keep it like that. In this situation (MIDI data or other data that look the same on all platforms), whether you use solution 1 or solution 2, you're fine. The problems start when you need to put a pointer in an event (not a MIDI event; say, a "waveform pointer" event). Which will happen sooner than later, I hope. On 32-bit platform, it will be fine (again, solution 1 and 2 give the same result here): /* 0 4 8 12 16 * | | | * | | | | | * | | | | | | | | | | | | | | | | | * |FRAMES |SUBFRMS|TYP|LEN|POINTER */ On 64 bit platform, though, we would have either: a) misalignment (bad) /* 0 4 8 12 16 * | | | * | | | | | | * | | | | | | | | | | | | | | | | | | | | | * |FRAMES |SUBFRMS|TYP|LEN| MISALIGNED PTR */ It corresponds to solution 1 ("in event type http://foltman.com/textpointer, the pointer is placed starting from byte 0 of payload"). Field placement specified in terms of bytes, no matter which platform we're on. b) padding (good-ish) /* 0 4 8 12 16 20 * | | | * | | | | | | | * | | | | | | | | | | | | | | | | | | | | | | | | | * |FRAMES |SUBFRMS|TYP|LEN|PADDING|POINTER........ */ It corresponds to solution 2 ("in event type http://foltman.com/textpointer, the pointer is a 64-bit field that follows the len field, whatever its natural placement for given platform may be"). Ie. this: struct LV2_WAVEFORM_EVENT { LV2_EVENT_HEADER hdr; // on 64-bit platforms, the compiler automatically puts 4 bytes of padding here void *some_ptr; // 4 bytes on x86, 8 bytes on x86-64 }; So, we have 0 bytes padding and offset 12 on x86 (etc) and 4 bytes padding and offset 16 on x86-64 (etc.). Hope the difference between both solutions is clearly visible now. If I understood correctly, you'd like to start from binary layout and *only then* make a C struct based on that design. Right? I would do exactly the opposite way - design a C (or Pascal, or whatever) struct in a way that leads to acceptable in-memory layout at least on a typical 32-bit and 64-bit platform (which is easy!). No, we don't need to do it for event *header* anymore (because the layout we pretty much agreed on is the same on 32-bit and 64-bit platform). We need to do it when creating new event types (ie. layout for payload). That's the part that might not be clear in what I wrote previously. I'm trying to imagine both header and typical situations in payload too. And from what I see, you seem to agree about the *payload* layouts being platform-dependent in some cases (which leads me to thinking that defining in terms of bytes is not the way to go for those cases). Try reading a 8-byte pointer (64-bit platform) from offset 12. It will be equally slow or even crash-provoking as if you read it from offset 11 on 32-bit platform. Which doesn't mean that we should use 8-byte alignment for every platform. We might use sizeof(void *) alignment, whatever it is locally. Any contraindications? (there is a contraindication, it seems; I've just written a short program to check reading/writing a buffer full of doubles from aligned and misaligned addresses, and ran it on my machine with crappy Pentium 4 CPU - seems that reading a double from address misaligned by 4 bytes is about 2.6 times as slow than reading from an aligned address, doesn't surprise me at all) Krzysztof

On Sun, 2007-12-02 at 23:02 +0100, Lars Luthman wrote: Agreed (enough digression and nitpicking!). What's in the payload doesn't matter (and everything is nicely aligned anyway). Does everyone like this event header? -DR-

On Sun, 2007-12-02 at 22:25 +0000, Krzysztof Foltman wrote: Works for me, I get my timestamp :) On to the buffer header (same as MIDI? more clever?) and the URI<->int mechanism.. -DR-

On Mon, 2007-12-03 at 02:29 +0100, Lars Luthman wrote: Fully agreed. int<->URI mapping is generic and widely useful. This does have me thinking about range though.. you can have an awful lot of URIs in a system. I guess the generic extension can map to, say, uint32_t, but the event extension can specifically say the event type URIs need to fit in uint16_t? Maybe doesn't matter but I think allowing a huge number of URIs is a good idea if it's just a single (or half) word, just in case. Though that's starting to sound like we're implementing a symbol system... probably going to be wanting one of those at some point regardless. Is that what this really is? (probably doesn't affect implementation much, just a hypothetical question). If it is just for URIs, we could maybe take advantage of prefixes and save some space in that table? lv2:Plugin is a lot nicer to deal with in all cases than http://lv2plug.in/ns/spec/lv2core#Plugin.... -DR-

On Mon, 2007-12-03 at 03:32 +0100, Lars Luthman wrote: What if, say, symbols are used as identifiers to shared data structures? If you've got a symbol per sample or something, it could get high fast. OSC has a specific symbol type we could use to get super fast comparison/lookup of things keyed by symbol. Parameters in each message being a symbol? That can definitely get high fast... Using a uint32_t (which is a reasonable limit for number of symbols in pretty much any system) and just not using out of range numbers for the event ones doesn't seem so bad, just in case. It's one line in a comment somewhere, BFD. Yeah, this extension probably shouldn't be concerned with the actual contents of the strings/symbols anyway (they can still be prefixed names in some cases). Just a thought.. -DR-

On Tue, 2007-12-04 at 09:42 +0000, Krzysztof Foltman wrote: Not really 'nicely'... essentially implementing the exact same thing n times. Why bother? The interface for the dynamic part would have to be figured out before this can be decided. ... did I stumble on to the Java 101 mailing list by mistake? ;) -DR-

On Wed, 2007-12-05 at 09:25 +0000, Krzysztof Foltman wrote: There are times when 'GoF Patterns in Java' style is appropriate for discussion solutions. This isn't one of them. -DR-

On Tue, 2007-12-04 at 09:42 +0000, Krzysztof Foltman wrote: I don't like having something this complicated in an extension that is going to be required if you just want to write a simple synth with a MIDI input. Is there really any need for adding and removing mappings dynamically? Just passing an array in the LV2_Feature data would be enough for me. --ll PS. Who keeps breaking the list headers? About 50% of the time "Reply to list" doesn't work on mails in this thread.

On Wed, 2007-12-05 at 09:45 +0000, Krzysztof Foltman wrote: And with an array you'd have const char* const* uris = feature_data; for (uint16_t i = 0; uris[i]; ++i) { if (!strcmp(uris[i], midi_type_uri)) { midi_event_id = i; break; } } The difference is not in the number of lines but in how many new functions and types are used. The fewer the better. Sure, in practice this will probably be done with a single function call to some plugin support library, but the actual spec should still be as simple as possible. If a plugin supports an event type (I assume that's what you meant) it can list it in its RDF file, and then the host can map it and that plugin will get an ID for that event type URI, regardless of whether the host or any other loaded plugin supports that event type or not. Though I don't think it's such a great idea to load plugins that need event types that the host doesn't know anything about, for the reasons you list below. If you want some sort of generic event where the host doesn't need to bother with the actual content you could define a single event type for that - maybe something like the refcounted objects you talked about earlier. Sure. It's just on instantiation. If you wanted to be smart you could have the host sort the array and pass the size as well and let the plugin do binary searches. --ll

On Wed, 2007-12-05 at 16:34 +0000, Krzysztof Foltman wrote: My idea is that if the plugin knows how to handle an event type it should list that type in its RDF data, and the host will assign it an integer value. A plugin that doesn't care about the event types, e.g. a generic quantizer, doesn't care about the event types, so any new mappings wouldn't matter to it. Yeah, if it's sorted. I don't really think it's needed though, iterating through a couple of hundreds of strings (in extreme cases) isn't that much work to do at instantiation time. --ll

On Wed, 2007-12-05 at 19:38 +0000, Krzysztof Foltman wrote: Assuming someone provides code to manage the symbol table, the increased work on plugin authors is 0 (you can still do an ignorant linear search through sorted array). Might as well. I think it would be better if the symbol thing was just a (simple) API where the implementation is left up to the host (or whatever), rather than defining some specific data structure to send to the plugin. We can deal with the details of a really good symbol system later... -DR-

On Wed, 2007-12-05 at 22:50 -0500, Dave Robillard wrote: That sounds OK. I suggest something like this: struct URI_Mapper { // call this with your URI and the host_data member - not RT safe uint16_t (map_function*)(const char* uri, void* host_data); // pass this as the second parameter to map_function() void* host_data; }; It doesn't provide a way for the host to say "I'm out of IDs!" though. Will that be needed? --ll

Dave Robillard wrote: Well, it's just atoms. Like in X, or Windows DDE. I'd prefer it to be kept general, but that's just me. After all, that memory will not be used except during plugin load or reconfiguration. Maybe it's that I can't imagine how would prefix-based mapping work reliably (would every URI be first turned into prefix form, then stored or looked up in the table?). Krzysztof

Dave Robillard wrote: char data? why not char data[0]? Krzysztof

On Sun, 2007-12-09 at 18:08 +0200, Nedko Arnaudov wrote: How would you access the data in code? (it'd be ugly/annoying) -DR-

On Sun, 2007-12-09 at 17:09 +0000, Krzysztof Foltman wrote: ..... duh. Try to note what something is a reply to /before/ responding ;) -DR-

On Sun, 2007-12-09 at 11:52 -0500, Dave Robillard wrote: n/m, char data[] is C99. Guess that works. -DR-

On Sun, 2007-12-09 at 23:20 +0100, Lars Luthman wrote: Ah, that was it. Back to char we go. I was thinking maybe having it be char* would be convenient for events where the actual data is in some pool somewhere (ie being able to reuse this struct in that case would be handy), but I guess that could just be another event type? char* does cause confusion though, as this thread made painfully clear earlier... -DR-