On 28 Nov 2007, at 00:05, Marc-Olivier Barre wrote:
On Nov 27, 2007 11:24 PM, Dave Robillard
[EMAIL PROTECTED] wrote:
I have said this a lot, and I will continue saying it more until
the end
of time because it's important: the fact that ports can
contain /anything/ is the fundamental
On Fri, Nov 23, 2007 at 02:40:29PM +0100, Clemens Ladisch wrote:
Dave Phillips wrote:
Clemens Ladisch wrote:
Portmidi designed is based on Windows' MME API which doesn't allow
applications to create ports visible to other applications.
Ah, that's good to know. Is that true for
On Wed, 2007-11-28 at 10:47 +, Krzysztof Foltman wrote:
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.
Using a number -
Lars Luthman wrote:
Using a number - URI mapping host feature is a good idea. With one byte
for the event type in each event header you get 256 different types per
plugin instance which is probably more than enough. With two bytes you
get 65536 different types per plugin instance which is
On Wednesday 28 November 2007, Krzysztof Foltman wrote:
[...]
I don't think it's a serious problem. Huge processing buffers are
not very useful in practice.
[...]
Actually, they're directly harmful most of the time!
For any graph with more than one plugin, and with plugins that use
internal
On Wednesday 28 November 2007, Krzysztof Foltman wrote:
[...]
- or introducing a 65536 samples milestone kind of event similar
to clear message in LZ compression format, separating events from
different 65536-sample eras :)
Why would you need to do this? Timestamps in Audiality 0.1.x are 16
On Wed, 2007-11-28 at 18:39 +0100, Rémi Thébault wrote:
By the way, for the moment I use FFTW for the frequency identification.
Is there a way to identify a frequency with quite high precision without
computing a big spectrum analysis ?
For a 0.7 Hz precision with fft, I need 65536 samples,
On Wednesday 28 November 2007, Rémi Thébault wrote:
By the way, for the moment I use FFTW for the frequency identification.
Is there a way to identify a frequency with quite high precision without
computing a big spectrum analysis ?
For a 0.7 Hz precision with fft, I need 65536 samples, what
On Wednesday 28 November 2007, Dave Robillard wrote:
[...]
The only problem that needs to be handled is how to get the type in
there. I would like to find a good solution to this problem that's
as extensible as URIs but doesn't actually stick a URI in the event
struct (there are a few other
On Wed, 2007-11-28 at 16:45 +, Krzysztof Foltman wrote:
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
On Wed, 2007-11-28 at 23:39 +0100, David Olofson wrote:
On Wednesday 28 November 2007, Dave Robillard wrote:
[...]
The only problem that needs to be handled is how to get the type in
there. I would like to find a good solution to this problem that's
as extensible as URIs but doesn't
On Wed, 2007-11-28 at 19:07 -0500, Dave Robillard wrote:
Same with LV2 ports; works perfectly for port types. Problem is,
sticking a URI in each /event/ is far too bloated/slow.
I am coming horribly late to this discussion, so I might be being thick,
but what happens if each event
On Thursday 29 November 2007, Dave Robillard wrote:
[...]
Same with LV2 ports; works perfectly for port types. Problem is,
sticking a URI in each /event/ is far too bloated/slow.
That's why I'm using a Port as the smallest connection unit, much
like LADSPA ports, so there is no need for an
On Thursday 29 November 2007, Dave Robillard wrote:
[...]
Well, sure, but big data is big data. In the typical case plugin
buffers are much smaller than the cache
[...]
Of course, but that's exactly what I'm talking about - large buffers,
and why it doesn't make sense to support them. :-)
If
Lars Luthman [EMAIL PROTECTED] writes:
struct Event_Port_Buffer {
uint32_t capacity;// number of elements in the array
uint32_t used_size; // number of _used_ elements
uint32_t event_count; // number of events (different from
Dan Mills [EMAIL PROTECTED] writes:
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
16 matches
Mail list logo
