30 Apr
2004
30 Apr
'04
7:28 a.m.
Hi!
Apparently our mailsever has been blacklisted by all-day-breakfast ...
Damned script-kiddies :(
So, since this discussion is kind of relevant here, I try get the
message thru anyway. Sorry Chris!
On tor, 2004-04-29 at 16:11, Chris Cannam wrote:
On Thursday 29 Apr 2004 2:19 pm, Jens M Andreasen
wrote:
Mmm .. This would replace, I think, all of your considerations on how to
extend LADSPA. It is (probably?) the only extension really needed. MIDI
is a very powerful protocol, and the beuty is that the client needs only
to implement those parts it needs to get going.
For a synthesizer one can ignore start, stop and pause as well as SMPTE,
but for a sequencer or arpeggiator timing would be the name of the game.
As a synthesizer developer I *could*, if I wished so, implement
running-status and thus discover that I have been disconnected, but it
is not required ...
mvh // Jens M andreasen
I think I will not be really, totally happy
before I see something
like:
void (*midi_msg)(LADSPA_Handle instance,
unsigned byte msg[4]);
This would be exactly equivalent to the existing run_synth(), would it
not? Chris
30 Apr
30 Apr
1:43 p.m.
On Friday 30 April 2004 11.23, Jens M Andreasen wrote:
[..]
As a synthesizer developer I *could*, if I wished so,
implement
running-status and thus discover that I have been disconnected, but
it is not required ...
That would be "active sensing" (0xFE IIRC) right? (Running status is
what allows senders to drop identical status bytes to save bandwidth.
Only optional for senders...)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
1 May
1 May
3:32 a.m.
Yes David! You are right, thank you very!
I have displaced my book on midi programming. It used to sit north east
of keyboard, just beside the trackaball ...
On fre, 2004-04-30 at 17:35, David Olofson wrote:
On Friday 30 April 2004 11.23, Jens M Andreasen
wrote:
[..]
As a synthesizer developer I *could*, if I wished
so, implement
running-status and thus discover that I have been disconnected, but
it is not required ...
That would be "active sensing" (0xFE IIRC) right? (Running status is
what allows senders to drop identical status bytes to save bandwidth.
Only optional for senders...)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
30 Apr
30 Apr
2:37 p.m.
[Jens M Andreasen]
On tor, 2004-04-29 at 16:11, Chris Cannam wrote:
as i understand it, this is not enough. the run_synth() method allows
you to run the synth for a continuous audio block with [MIDI] events
interspersed at arbitrary timestamps, while with midi_msg() you'd
have to split audio blocks to match event timestamps, which is messy
and performance-unfriendly.
tim
On Thursday 29 Apr 2004 2:19 pm, Jens M Andreasen
wrote:
Mmm .. This would replace, I think, all of your considerations on how to
extend LADSPA. It is (probably?) the only extension really needed. MIDI
is a very powerful protocol, and the beuty is that the client needs only
to implement those parts it needs to get going. I think I will not be really, totally happy
before I see something
like:
void (*midi_msg)(LADSPA_Handle instance,
unsigned byte msg[4]);
This would be exactly equivalent to the existing run_synth(), would it
not?
1 May
1 May
4:06 a.m.
Hi Tim!
void (*midi_msg)(LADSPA_Handle instance,
unsigned byte msg[4]);
.. is a four byte message.
I should have included some kind of man page:
msg[0] = midi_status;
msg[1] = midi_data_1;
msg[2] = midi_data_2;
msg[3] = sample_offset; // counting from most recent rendering.
Personally I can ignore sample_offset, but to others
it is a
prerequisite.
... and I realize now that I should not totally ignore sample_offset. I
would probably try to change the internal status to fit with 64/32/16
samples, or whatever is the rendering fashion of the day.
And one more thing: The host should do the sorting and interleaving of
events from those devices it listens to. Not that it will break anything
if it doesn't, but if it do, then everything will be so much more tight
and solid. That is to say that the client(s) need not to bother about
time, except for beeing aware that time might not be 100% linear.
mvh // Jens M Andreasen
On fre, 2004-04-30 at 18:25, Tim Goetze wrote:
[Jens M Andreasen]
On tor, 2004-04-29 at 16:11, Chris Cannam wrote:
as i understand it, this is not enough. the run_synth() method allows
you to run the synth for a continuous audio block with [MIDI] events
interspersed at arbitrary timestamps, while with midi_msg() you'd
have to split audio blocks to match event timestamps, which is messy
and performance-unfriendly.
tim On Thursday 29 Apr 2004 2:19 pm, Jens M Andreasen
wrote:
Mmm .. This would replace, I think, all of your considerations on how to
extend LADSPA. It is (probably?) the only extension really needed. MIDI
is a very powerful protocol, and the beuty is that the client needs only
to implement those parts it needs to get going. I think I will not be really, totally happy
before I see something
like:
void (*midi_msg)(LADSPA_Handle instance,
unsigned byte msg[4]);
This would be exactly equivalent to the existing run_synth(), would it
not?
3 May
3 May
8:47 a.m.
[Jens M Andreasen]
I should have included some kind of man page:
agree about the sorting of events (which btw is mandatory for the
host with run_synth() following <dssi.h>).
however, i insist that the midi_msg() idea deters performance by
forcing the host to split audio blocks (cache coherence and more
indirect function calls). in effect, run_synth() demands less from the
plugin (no MIDI byte stream parser with error correction mechanisms
needed), thus results in more readable event parsing code and leaves
the decision about sub-cycle length to the plugin, which is a good
thing.
it also seems worth noting that forcing an event's audio frame offset
into 8 bits is a bit meagre. it's not uncommon to run at 2+ k frames /
audio cycle, and some interfaces and systems won't go below 512
frames/cycle in the first place. off-line processing may even involve
a lot longer audio cycles.
tim
msg[0] = midi_status;
msg[1] = midi_data_1;
msg[2] = midi_data_2;
msg[3] = sample_offset; // counting from most recent rendering.
Personally I can ignore sample_offset, but to
others it is a
prerequisite.
... and I realize now that I should not totally ignore sample_offset. I
would probably try to change the internal status to fit with 64/32/16
samples, or whatever is the rendering fashion of the day.
And one more thing: The host should do the sorting and interleaving of
events from those devices it listens to. Not that it will break anything
if it doesn't, but if it do, then everything will be so much more tight
and solid. That is to say that the client(s) need not to bother about
time, except for beeing aware that time might not be 100% linear.
7600
days inactive
7603
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
3 participants
participants (3)
-
David Olofson -
Jens M Andreasen -
Tim Goetze