john13@garfield.UUCP (08/10/87)
--
Chuck McManis, in an article I read a couple of minutes ago, suggested the
need for a SYNTH: and a MIDI: device. I would like to suggest a more
generalized series of devices that people could construct, ones dealing with
any form of I/O that a lot of people would like to do on the Amiga.
These include (and this is just off the top of my head, please add any that
come to mind):
MUSIC: - you send it write commands in an understandable form, specifying
pitch, duration, optional pointer to waveform, etc and it plays it
for you. You could use DoIO, SendIO and the like to either do a
quick sound-effect or queue io requests for an entire song, useful
if you wanted to recalculate the waveforms as you went.
ANIM: - you give it the sorts of parameters that you can specify in the new
IFF Anim formats and it does it for you. So you don't have to
re-invent the wheel with each program, and the interface could be
set up and documented in such a way that you don't have to be able to
write DVideo or Animator to be able to use it.
DRAW: - all the left-out functions like arcs, and the ones that require a lot
of rastport-twiddling could go in here.
PRT: - well, it exists, but it could be greatly improved in future OS
releases. Maybe PRINT:, a superset of PRT:? I want to see an icon,
like you get with most other windowing systems, and a Tooltype that
says "I am a DPaint picture so when I am dropped on the PRINT: icon
you should load sys:utilities/IFF_printer and print me". Come to
think of it, why don't any programs that create icons let you specify
the default tool, such as your favourite IFF viewer?
I can't think of any new forms of input that I am in need of, but I'm sure
there are some...hmmm...I have an old lightpen lying around...PEN:?
Now you may say that some of these functions, especially anim and draw, are
better suited to librarifying than devicification. I would like to see PD
anim and draw libraries too, but I think the Amiga's powerful device system
should be put to use so that more can be done just by sending clear text to
a named device. In the case of things like pointers, these could be easily
fprintf'ed under program control. Where you didn't have to access the system
structures like that, it would be highly useful to be able to create music,
animation, etc *without* a lot of programming overhead. Of course an ideal
device would optionally *create* the source code to do it all again later :-).
Just a thought - opposing views encouraged. Remember, libraries for programmers
and *equivalent devices* for non-experts or non-programmers.
John
--
"I would have promised those terrorists a TRIP TO DISNEYLAND if it would have
gotten the hostages released. I thank God they were satisfied with the
missiles and we didn't have to go to that extreme."
-- preliminary draft of Ollie's testimonyrichard@gryphon.CTS.COM (Richard Sexton) (08/11/87)
In article <3866@garfield.UUCP> john13@garfield.UUCP writes: >-- >Chuck McManis, in an article I read a couple of minutes ago, suggested the >need for a SYNTH: and a MIDI: device. I would like to suggest a more >generalized series of devices that people could construct, ones dealing with >any form of I/O that a lot of people would like to do on the Amiga. > >DRAW: - all the left-out functions like arcs, and the ones that require a lot > of rastport-twiddling could go in here. > >John >-- What a novel idea. Like Mac's quickdraw ? This idea appeals to me. If we kept the object list around, we could support PDL printers instead of just bitmapped ones. Actually, I *think* I know somebody already working on this. -- Richard Sexton INTERNET: richard@gryphon.CTS.COM UUCP: {akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard "It's too dark to put the key in my ignition..."
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (08/11/87)
[ Of course I know UNIX. Some of my best friends are UNIX. ] In article <3866@garfield.UUCP> john13@garfield.UUCP writes: >-- >Chuck McManis, in an article I read a couple of minutes ago, suggested the >need for a SYNTH: and a MIDI: device. I would like to suggest a more >generalized series of devices [ ... ] > >MUSIC: - you send it write commands in an understandable form, specifying > pitch, duration, optional pointer to waveform, etc and it plays it > for you. I like this one. However, if you think about it *real* hard, this is how the existing audio.device works. Granted, it isn't very straightforward. I think the design of the audio.device was motivated more by the hardware it was running on than by a more abstract, easily programmable concept. I would have liked to see an interface that needed: Wavetable, sampling rate (samples/sec), and volume (0-63). Instead, we have to do all this weird conversion. Sigh. > You could use DoIO, SendIO [ ... ] Not with a DOS handler, you can't. You have to "packetize" everything, and you can't (according to DOS manuals) have more than one outstanding packet on a handler port at any time. Can you say, "Extra layer of software"? >ANIM: - you give it the sorts of parameters that you can specify in the new > IFF Anim formats and it does it for you. [ ... ] Sounds to me this would be better as a seperate program running in a pipe stream. DPaint tosses ILBMs at the pipe. This program picks them up, does the anim magic, and tosses the anim stream out another file (which could be another pipe, like, the input to ShowANIM for example). >DRAW: - all the left-out functions like arcs, and the ones that require a lot > of rastport-twiddling could go in here. > Nope, better as a shared library. Having half your drawing code doing library calls, and the other half doing I/O requests could be very messy. >PRT: - well, it exists, but it could be greatly improved in future OS > releases. [ ... ] Hear, hear! I think the current implementation is too limited. I think it should have been done like this: You open PRT: and write to it. DOS takes the data and tosses it at the printer.device. The printer.device massages the data, and then tosses it at a filename in AmigaDOS space. This filename would be specified via "Preferences". Typically, you'd tell it to write to SER: or PAR: However, you could also tell it to write to SYS:printout. There are problems with this idea, though. The main one I can think of is that the printer.device would *have* to be written as a DOS process, not a task (since it's making DOS I/O requests). I don't know how complicated that would be. However, I think the benefits would far outweigh the initial problems of making it happen. It would make the printer.device much more flexible. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor