From owner-freebsd-multimedia Mon Oct 20 14:16:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA20470 for multimedia-outgoing; Mon, 20 Oct 1997 14:16:29 -0700 (PDT) (envelope-from owner-freebsd-multimedia) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA20464 for ; Mon, 20 Oct 1997 14:16:24 -0700 (PDT) (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Mon, 20 Oct 1997 17:13:42 -0400 (EDT) Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1) id AA02898; Mon, 20 Oct 97 17:13:40 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id RAA22956; Mon, 20 Oct 1997 17:09:22 -0400 Message-Id: <19971020170921.04433@ct.picker.com> Date: Mon, 20 Oct 1997 17:09:21 -0400 From: Randall Hopper To: Luigi Rizzo Cc: multimedia@freebsd.org Subject: Re: Who is interested in /dev/midi and /dev/synth ? References: <19971016194418.46875@ct.picker.com> <199710170426.FAA13110@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199710170426.FAA13110@labinfo.iet.unipi.it>; from Luigi Rizzo on Fri, Oct 17, 1997 at 05:26:21AM +0100 Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo: |> However, if across the group we're lacking T T or E for a rewrite, unless |> you know of some prohibitive bugs in the existing synth code, it might be a |> good idea to lean toward working it so that the synth system's existing |> external APIs can be "plugged in" so-to-speak across a DMZ (your clean code | |the external API is the last think I want to change -- as in the case |of the sound driver, i implemented most of the voxware interface first, |and then tried to define a new one to cover the missing |functionlaities. But the problem I think is that even pluggin in a |module without understanding what it does it's a hard task. Plus... Sorry, I shouldn't have used the word "external". What I meant was the APIs between the sound driver "shell" and each of the individual sequencer drivers (like probe, attach, ioctl, etc.). I was thinking of these sequencer APIs as external to a particular sequencer driver (in terms of plugging into the sound driver shell), but of course they're still internal to the sound driver as a whole. Sorry about that. |... the real thing I am missing is not how to code the driver, for that |I can borrow from the existing one. The real problem is what the synth |is expecting to receive in terms of communication with the system. I |guess it needs, for each note, a set of parameters identifying the note |to play, and perhaps some timing reference to relate it to other notes. |Also what kind of feedback is the driver supposed to give back to the |application --- things like "i am about to finish with this note please |send me more..." etc. Once I understand this, i guess i can be really |productive. And for that it is more important to have a high level |understanding of what the synth should do, rather than low level driver |programming. It is the former experience i am severely lacking an |looking for help. if you know about that, or know somebody who can |help, please let me know. | |>From these discussions I am slowly figuring out what should the |interface be, but more is needed... I've not done any sequencer programming myself, but the two references I'm aware of are are: 1) Chapter 4 (pp 32-44) from Hannu's snd-sdk-doc-0.1.ps, and 2) http://www.4front-tech.com/pguide/midi.html at 4-Front. The latter is a pretty anemic write-up. The former is much more interesting. Let me know if you don't have a copy of this snd-sdk-doc-0.1.ps file and I'll be glad to get one in the mail to you. Thanks, Randall