From: Simon Wright on
John McCabe <john(a)nospam.assen.demon.co.uk.nospam> writes:

> BTW - in case anyone's interested, the MIDI format for the synth I'm
> interested in is defined at:
>
> http://www.kawaius-tsd.com/OM/K_SYNTH/K1WAVE~1.PDF

You're going to have fun using unchecked conversion (whether by
Unchecked_Conversion or overlay), considering that the data dumps are
indefinite length (EOX-terminated). Won't you just have to read 4 octets
at a time until EOX? (rather like an HTTP request).

I think I agree with Dmitry, "reading the octet stream or else what is
natural for the device or the protocol at hand, and then constructing
the necessary Ada objects on the fly".
From: John McCabe on
Simon Wright <simon(a)pushface.org> wrote:

>John McCabe <john(a)nospam.assen.demon.co.uk.nospam> writes:
>
>> BTW - in case anyone's interested, the MIDI format for the synth I'm
>> interested in is defined at:
>>
>> http://www.kawaius-tsd.com/OM/K_SYNTH/K1WAVE~1.PDF
>
>You're going to have fun using unchecked conversion (whether by
>Unchecked_Conversion or overlay), considering that the data dumps are
>indefinite length (EOX-terminated). Won't you just have to read 4 octets
>at a time until EOX? (rather like an HTTP request).

Nah - they're fixed length in this case.

>I think I agree with Dmitry, "reading the octet stream or else what is
>natural for the device or the protocol at hand, and then constructing
>the necessary Ada objects on the fly".

Thanks for that. I'll bear it in mind but, as I sort of mentioned, for
this synth and for the purposes I want it it looks like the data is a
fixed length, and they're all terminated with EOX anyway.

That is unless (as I hope is NOT the case) any other MIDI data is
interspersed with the SysEx messages. I would hope not but you never
know. Guess it depends on a number of things.
From: Simon Wright on
John McCabe <john(a)nospam.assen.demon.co.uk.nospam> writes:
> "Jeffrey R. Carter" <spam.jrcarter.not(a)spam.acm.org> wrote:

>>I can't tell you whether the tagged approach would work, because
>>programming by extension is a bad idea, and I avoid it whenever
>>possible.
>
> It's a good laugh though, and can be a useful think to know about if
> your work doesn't involve anything that needs to be particularly fast,
> reliable or safe :-}

Not my experience. Though the example I have in mind uses extension in
the framework; most project-specific code doesn't.
From: John McCabe on
John McCabe <john(a)nospam.assen.demon.co.uk.nospam> wrote:

>>I think I agree with Dmitry, "reading the octet stream or else what is
>>natural for the device or the protocol at hand, and then constructing
>>the necessary Ada objects on the fly".

>Thanks for that. I'll bear it in mind but, as I sort of mentioned, for
>this synth and for the purposes I want it it looks like the data is a
>fixed length, and they're all terminated with EOX anyway.

>That is unless (as I hope is NOT the case) any other MIDI data is
>interspersed with the SysEx messages. I would hope not but you never
>know. Guess it depends on a number of things.

Just checked the MIDI implementation doc; the SysEx messages are all
fixed length starting with a Status octet (16#F0# - nearly gave away
what I've been using recently by writing 0xF0 there :-) and ending in
EOX (16#F7#). Those are the only two octets in the stream that will
have their most significant bit set so I'd need to check anything that
comes in with a set MSB and dump it unless it's a status or EOX octet.
Everything else in the meantime can be shoved in the buffer until the
number of bytes I expect are received.

In saying that, it suggests that, as I'm only ever interested in SysEx
messages I've explicitly requested, then I should be in a position to
just create an object of the expected message type and fill it in on
the fly anyway.

Thanks for that.

From: tmoran on
>I think I agree with Dmitry, "reading the octet stream or else what is
>natural for the device or the protocol at hand, and then constructing
>the necessary Ada objects on the fly".

CLAW's bitmap routines have an abstract Root_DIBitmap_Type, with monochrome,
VGA, 24 bit color, etc derived types. For reading a bmp file
function Read (Filename : in String)
return Claw.Bitmaps.Root_DIBitmap_Type'class;
internally reads the header bytes, then creates an object of the correct
derived type, reads the data into it, and returns that. Works just fine.

I don't know about MIDI, but for wav and video Windows generally assumes
you can't do accurate timing, but it can. So your routines either operate
at a high level or are called as callbacks if they have to execute at an
accurate time. Ada tasking works just fine for me with audio/video stuff.