Thinking of using Ada for a job at home. Couple of questions first.
in [ADA]
|
Prev: Presentations on-line - Ada&SPARK for Education&Research
Next: Thinking of using Ada for a job at home. Couple of questionsfirst.
From: Simon Wright on 3 Mar 2010 15:56 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 3 Mar 2010 16:00 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 3 Mar 2010 16:00 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 3 Mar 2010 16:10 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 3 Mar 2010 16:35
>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. |