On Fri, 2007-11-30 at 09:45 +, Krzysztof Foltman wrote:
Dave Robillard wrote:
We could use float I guess to save a bit of space, but I definitely
prefer floating point. Fixed point is just a PITA, modern CPUs are much
faster at FP anyway, why bother?
1. The modern CPUs are much
On Fri, 2007-11-30 at 11:23 +0100, David Olofson wrote:
On Friday 30 November 2007, Krzysztof Foltman wrote:
[...several points that I totally agree with...]
If you use integers, perhaps the timestamps should be stored as
delta values.
That would seem to add complexity with little gain,
On Fri, 2007-11-30 at 10:42 +, Krzysztof Foltman wrote:
Dave Robillard wrote:
Sigh. In /this case/ they are the same, because the data directly
follows
Sort it out with gcc, not with me :)
The struct does not actually exist, its sizeof is irrelevant.
And if you meant that
On Fri, 2007-11-30 at 11:10 +, Krzysztof Foltman wrote:
Dave Robillard wrote:
MIDI. In short: don't rock the boat; all this Jack/LV2 MIDI stuff is
still getting off the ground...
Well, I see your point. Again, I'll start worrying (or defining
extensions) when it'll be necessary.
On Sat, 2007-12-01 at 14:03 -0500, Dave Robillard wrote:
We have working plugins, MIDI, dynamic
parameters, OSC, toolkit agnostic embeddable GUIs;
Clarification: The GUI extension is toolkit agnostic, the GUIs are not.
Not that it matters to me.
--ll
signature.asc
Description: This is a
Dave Robillard wrote:
Read the comment... the buffer format couldn't be more clear.
That was the problem - the comment contradicted the code, but - as human
language is usually more ambiguous than C code - I assumed that the
true intention is in the code, not in the comment.
Just to clear
On Sat, 2007-12-01 at 14:09 -0500, Dave Robillard wrote:
On Fri, 2007-11-30 at 16:21 +0200, Nedko Arnaudov wrote:
Krzysztof Foltman [EMAIL PROTECTED] writes:
Lars Luthman wrote:
non-standard hacks in a specification. But with the current event header
proposal we don't have a
On Sat, 2007-12-01 at 20:13 +0100, Lars Luthman wrote:
On Sat, 2007-12-01 at 14:03 -0500, Dave Robillard wrote:
We have working plugins, MIDI, dynamic
parameters, OSC, toolkit agnostic embeddable GUIs;
Clarification: The GUI extension is toolkit agnostic, the GUIs are not.
Not that it
Krzysztof Foltman wrote:
i += (events[i].size + 7)~7;
Oops, that should be:
i += (event[i].size + 7) 3;
:)
Krzysztof
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
On Sat, 2007-12-01 at 21:49 +0100, David Olofson wrote:
On Saturday 01 December 2007, Dave Robillard wrote:
[...]
Taking a step back, it would be nice to have these events (being
generic) able to use something other than frame timestamps, for
future dispatching/scheduled type event
On Sat, 2007-12-01 at 22:19 +0100, David Olofson wrote:
On Saturday 01 December 2007, Dave Robillard wrote:
[...non audio time timestamps...]
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
On Sat, 2007-12-01 at 14:56 -0500, Dave Robillard wrote:
No argument that it's faster. With separate int fractional parts it's
even probably cleaner. I may be convinced...
Taking a step back, it would be nice to have these events (being
generic) able to use something other than frame
On Sat, 2007-12-01 at 23:23 +0100, Krzysztof Foltman wrote:
Dave Robillard wrote:
Taking a step back, it would be nice to have these events (being
generic) able to use something other than frame timestamps, for future
dispatching/scheduled type event systems.
I think there's certain
On Sun, 2007-12-02 at 00:15 +, Krzysztof Foltman wrote:
Dave Robillard wrote:
What is the point of having two separate event definitions when one will
do for both, though?
Perhaps, if we go 64-bit (although I still think it's overkill!) it
might make sense to make a timestamp a sort
Dave Robillard wrote:
I still don't see where you're getting all this messy code stuff.
Adding 8 to a pointer isn't any more or less messy than adding 16 to a
pointer.
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
On Sun, 2007-12-02 at 01:26 +, Krzysztof Foltman wrote:
Dave Robillard wrote:
I still don't see where you're getting all this messy code stuff.
Adding 8 to a pointer isn't any more or less messy than adding 16 to a
pointer.
uint32_t *p = some_int_array[0];
p += 7;
Q: Where does p
16 matches
Mail list logo
