Sound programming

Discussion in 'C Programming' started by kid joe, Jul 7, 2008.

  1. kid joe

    kid joe Guest

    Hello

    I've got interested in learning some basic sound programming bits in
    C... mainly I want to know how to go about accessing the sound devices -
    reading from them mainly - in windows and linux... I'd kind of like to be
    able to do it without a whole bunch of extra garbage added in there - by
    this I mean that I know in windows there are a million sound programming
    packages that make the whole process "easier" - there are also a few in
    linux but I think the raw stuff I'm interested in understanding is a bit
    more simple in linux b/c of the way devices work in it.

    So if anyone can point me at a place to start - maybe some really raw
    source code for linux and windows - I would really appreciate it.

    Thanks!
     
    kid joe, Jul 7, 2008
    #1
    1. Advertising

  2. In article <>,
    kid joe <> wrote:

    >I've got interested in learning some basic sound programming bits in
    >C... mainly I want to know how to go about accessing the sound devices -
    >reading from them mainly - in windows and linux...


    There is no mechanism provided by the standard C language to handle
    sound devices (or graphics, or mice, or printers, or any other kind of
    device.) All sound handling is system and operating-system dependant.

    >So if anyone can point me at a place to start - maybe some really raw
    >source code for linux and windows - I would really appreciate it.


    You should check with newsgroups that are specific to your
    operating systems, and also with information sources specific
    to the brand and model of sound hardware. "raw" sound processing
    might require that you program at the device driver level in order
    to have the privilege to access the necessary hardware registers.

    --
    So you found your solution
    What will be your last contribution?
    -- Supertramp (Fool's Overture)
     
    Walter Roberson, Jul 7, 2008
    #2
    1. Advertising

  3. kid joe

    cr88192 Guest

    "Malcolm McLean" <> wrote in message
    news:...
    > "kid joe" <> wrote in message
    >> I've got interested in learning some basic sound programming bits in
    >> C... mainly I want to know how to go about accessing the sound devices -
    >> reading from them mainly - in windows and linux... I'd kind of like to be
    >> able to do it without a whole bunch of extra garbage added in there - by
    >> this I mean that I know in windows there are a million sound programming
    >> packages that make the whole process "easier" - there are also a few in
    >> linux but I think the raw stuff I'm interested in understanding is a bit
    >> more simple in linux b/c of the way devices work in it.
    >>
    >> So if anyone can point me at a place to start - maybe some really raw
    >> source code for linux and windows - I would really appreciate it.
    >>

    > It is rather more involved than you think.
    >
    > The problem is that audio devices need to be fed a continuous stream of
    > raw bits, whilst generally you want the processor to spend most of its
    > time dealing with the rest of the program, like moving space invaders
    > about the screen.
    >


    yes, and sadly, getting this write without blocking the app (or causing
    annoying auditory artifacts) is a little harder than it may seem (or at
    least for single-threaded apps).

    > So unless you want to do difficult multi-tasking programming at the device
    > level, you need a certain layer of abstraction. the question then becomes
    > "which one?". For space invaders you can probably get away with an
    > interface that says "play sound". It puts a bleep or an explosion into the
    > audio queue, return scontro, to you almost immediately, and a millesecond
    > or so later you'll hear the sound on the speakers.
    > For a more advanced use of audio, this isn't sufficient. You'll want to be
    > able to cancel jobs, to submit long sequences instead of tiny clips, to
    > change the volume, to stream sound in from a backing store, maybe to
    > synthesise samples on the fly.
    >
    > So it becomes difficult to know what level of abstration to use. Too low
    > and you're doing messy parallel programming, too high and you're calling
    > Midi instruments and the like when you just want to say "play this".
    >


    a generally workable approach I had found was to implement a mixer, which
    created temporary "mix streams". these streams basically just provided a
    means for the mixer to demand a certain number of samples. the streams
    themselves had a various info (current origin, spatial velocity, ...)
    allowing for effects like doppler shifting (as well as just the "things are
    quieter when far away" effect).

    these were typically structs making use of callbacks.

    playing a sound typically involved creating a stream with the right
    properties (handled automatically by various "play a sound") functions, the
    stream typically automatically destroying itself when done.

    the interface also worked fairly well with playing audio from videos, and
    from songs in the form of mp3s (typically, sound effects are just buffered
    into ram, but songs are better streamed since they can take a decent-sized
    chunk of memory to store).

    whatever else can be played so long as the right callbacks could be
    provided.


    note: callbacks may be passed a chunk of "user data" (as well as a stream
    id), which is another useful trick here, and is put in the struct when
    creating the stream. this is usually a pointer holding whatever it is the
    stream-specific functions feel is important (GTK does similar...).


    also note:
    as an interesting effect of having doppler shifting and other effects, not
    all of the streams may be strictly temporally in-sync, since moving away
    from a stream causes it to be played slower and moving towards it makes it
    play faster (I make sounds just "cut out" near mach-1, since otherwise there
    are annoying zero-division issues).

    a related trick was to add a delay calculated from the distance of the sound
    from the camera, such that, say, a distant explosion will take a little
    while for the sound to hit (first we see the explosion, and then the sound
    hits a short time later).

    note that as an effect of the geometry: when one is far away from an audio
    source they are out of sync with it (temporally and possibly also in terms
    of rate), but as they move closer the sync is regained, such that upon
    reaching the source it is playing more or less in realtime (and other
    sources they were nearby originally have moved out of sync).

    ....

    one notable lacking effect though is echo-modeling (or dealing with sounds
    being otherwise blocked or distorted by geometry), since this is
    computationally expensive (an "echo effect", "dampen effect", ... being much
    cheaper).


    > --
    > Free games and programming goodies.
    > http://www.personal.leeds.ac.uk/~bgy1mm
    >
     
    cr88192, Jul 8, 2008
    #3
  4. kid joe wrote:

    > Hello
    >
    > I've got interested in learning some basic sound programming bits in
    > C... mainly I want to know how to go about accessing the sound devices -
    > reading from them mainly - in windows and linux... I'd kind of like to be
    > able to do it without a whole bunch of extra garbage added in there - by
    > this I mean that I know in windows there are a million sound programming
    > packages that make the whole process "easier" - there are also a few in
    > linux but I think the raw stuff I'm interested in understanding is a bit
    > more simple in linux b/c of the way devices work in it.
    >
    > So if anyone can point me at a place to start - maybe some really raw
    > source code for linux and windows - I would really appreciate it.
    >
    > Thanks!


    Sound programming in C is involved and highly system dependent. A cross
    platform helper library would _be_ "a bunch of garbage added in there", and
    would not (nessescarily) reflect the way the sound hardware works in
    practice.

    The least crufty library I know of only does sound output --
    http://xiph.org/ao/

    If you are interested in sound synthesis or analysis I would recommend Chuck
    instead -- http://chuck.cs.princeton.edu/

    Of course, there is always Pure Data (http://puredata.info/) or its
    commercial sibling, Max/MSP (http://www.cycling74.com/)

    -Sigmund
     
    Sigmund Lappegård Lahn, Jul 8, 2008
    #4
  5. kid joe

    kid joe Guest

    On Sun, 07 Jun 2009 21:42:55 +0100, kid joe wrote:
    <snip>


    Hi all,

    Id like to point out that the above message was a forgery not sent by me.
    I know that sound programming is OT here.

    Cheers,
    Joe


    --
    ...................... o _______________ _,
    ` Good Morning! , /\_ _| | .-'_|
    `................, _\__`[_______________| _| (_|
    ] [ \, ][ ][ (_|
     
    kid joe, Jun 8, 2009
    #5
  6. kid joe

    Guest

    On 8 June, 08:57, kid joe <> wrote:
    > On Sun, 07 Jun 2009 21:42:55 +0100, kid joe wrote:


    > Id like to point out that the above message was a forgery not sent by me.
    > I know that sound programming is OT here.
    >
    > Cheers,
    > Joe
    >
    > --
    >        ......................  o    _______________           _,
    >       ` Good Morning!  ,      /\_  _|             |        .-'_|
    >       `................,     _\__`[_______________|       _| (_|
    >                              ] [ \, ][         ][        (_|


    I *thought* it was odd that the ascii art was missing!
     
    , Jun 8, 2009
    #6
  7. kid joe

    BartC Guest

    "kid joe" <> wrote in message
    news:h0ig9p$nqn$...
    > On Sun, 07 Jun 2009 21:42:55 +0100, kid joe wrote:
    > <snip>
    >
    >
    > Hi all,
    >
    > Id like to point out that the above message was a forgery not sent by me.
    > I know that sound programming is OT here.


    I was thinking of offering him this program to help him get started. I'm
    glad I didn't bother now.

    #include <stdio.h>

    int main(void){
    printf("\a");
    }

    --
    Bart
     
    BartC, Jun 8, 2009
    #7
  8. kid joe

    cr88192 Guest

    "BartC" <> wrote in message
    news:Ha5Xl.39495$...
    > "kid joe" <> wrote in message
    > news:h0ig9p$nqn$...
    >> On Sun, 07 Jun 2009 21:42:55 +0100, kid joe wrote:
    >> <snip>
    >>
    >>
    >> Hi all,
    >>
    >> Id like to point out that the above message was a forgery not sent by me.
    >> I know that sound programming is OT here.

    >
    > I was thinking of offering him this program to help him get started. I'm
    > glad I didn't bother now.
    >
    > #include <stdio.h>
    >
    > int main(void){
    > printf("\a");
    > }
    >


    would be ammusing though if there were an OS where one could do, for
    example, midi via printf statements...

    all one has to do is embed each midi command into a form vaguely resembling
    ANSI codes (but with no timing info, so the app would have to implement its
    own time delays and send midi in real-time, or the delays would be
    optional...).


    ok, going OT:

    (actually, I am almost tempted now to make a textual midi serialization...
    unlike traditional midi it would be "human readable...", and potentially
    even "human editable", and FWIW we need not care much if it is 2x-5x the
    original size...).

    T8 C0,1 N0,39,127 T64 M0,39

    delay 8 ticks; program-change chan=0 to instrument=1; note-on chan=0,
    note=39, vel=127;
    delay 64 ticks; note-off chan=0, note=39, vel=127 (default value here).

    or, in summary: play a 440Hz note on a piano, with the whole sequence taking
    0.6s (default: rate=120, q_note=1s).

    a more verbose notation could be easier to follow (for example, command
    nmonics in place of letters), but could make sequences intollerably long,
    and a learning curve of associating letters with commands may-well be
    reasonable (after all, whoever would still have to deal with the "rest" of
    midi terribleness...).


    or such...


    > --
    > Bart
     
    cr88192, Jun 8, 2009
    #8
  9. "cr88192" <> writes:

    > (actually, I am almost tempted now to make a textual midi serialization...
    > unlike traditional midi it would be "human readable...", and potentially
    > even "human editable", and FWIW we need not care much if it is 2x-5x the
    > original size...).
    >
    > T8 C0,1 N0,39,127 T64 M0,39
    >
    > delay 8 ticks; program-change chan=0 to instrument=1; note-on chan=0,
    > note=39, vel=127;
    > delay 64 ticks; note-off chan=0, note=39, vel=127 (default value here).
    >
    > or, in summary: play a 440Hz note on a piano, with the whole sequence taking
    > 0.6s (default: rate=120, q_note=1s).


    GW-BASIC's PLAY statement did something like this. Simpler, because it
    was for a PC speaker instead of MIDI, and with a more music-like
    notation (you wrote notes like "a4" rather than giving frequency and
    duration), but certainly fun.
     
    Nate Eldredge, Jun 8, 2009
    #9
  10. kid joe

    luserXtrog Guest

    On Jun 8, 11:25 am, "cr88192" <> wrote:
    > "BartC" <> wrote in message
    >
    > news:Ha5Xl.39495$...
    >
    >
    >
    > > "kid joe" <> wrote in message
    > >news:h0ig9p$nqn$...
    > >> On Sun, 07 Jun 2009 21:42:55 +0100, kid joe wrote:
    > >> <snip>

    >
    > >> Hi all,

    >
    > >> Id like to point out that the above message was a forgery not sent by me.
    > >> I know that sound programming is OT here.

    >
    > > I was thinking of offering him this program to help him get started. I'm
    > > glad I didn't bother now.

    >
    > > #include <stdio.h>

    >
    > > int main(void){
    > > printf("\a");
    > > }

    >
    > would be ammusing though if there were an OS where one could do, for
    > example, midi via printf statements...
    >
    > all one has to do is embed each midi command into a form vaguely resembling
    > ANSI codes (but with no timing info, so the app would have to implement its
    > own time delays and send midi in real-time, or the delays would be
    > optional...).
    >
    > ok, going OT:
    >
    > (actually, I am almost tempted now to make a textual midi serialization....
    > unlike traditional midi it would be "human readable...", and potentially
    > even "human editable", and FWIW we need not care much if it is 2x-5x the
    > original size...).
    >
    > T8 C0,1 N0,39,127 T64 M0,39
    >
    > delay 8 ticks; program-change chan=0 to instrument=1; note-on chan=0,
    > note=39, vel=127;
    > delay 64 ticks; note-off chan=0, note=39, vel=127 (default value here).
    >
    > or, in summary: play a 440Hz note on a piano, with the whole sequence taking
    > 0.6s (default: rate=120, q_note=1s).
    >
    > a more verbose notation could be easier to follow (for example, command
    > nmonics in place of letters), but could make sequences intollerably long,
    > and a learning curve of associating letters with commands may-well be
    > reasonable (after all, whoever would still have to deal with the "rest" of
    > midi terribleness...).
    >
    > or such...
    >


    I wrote a midi "compiler" years ago to generate .mid files (too cheap
    to buy a drum machine). It read a line-oriented sequence of notes,
    that was something like this:
    <measure>.<beat> <note> <duration>
    1.1 A4 .4
    1.2 C5 .3
    1.3 E5 .2
    1.4 A5 .1

    Using the duration number, it would add the corresponding note-off
    later. IIRC, the midi file format requires a sequence number for
    each event, so "compiling" amounted to simply sorting the entries
    by number.

    But note-by-note quickly became tedious, so it eventually got a
    macro-processor, too. It's safely on a dead disk that I've yet
    get looked at.

    --
    lxt
     
    luserXtrog, Jun 9, 2009
    #10
  11. kid joe

    cr88192 Guest

    "luserXtrog" <> wrote in message
    news:...
    On Jun 8, 11:25 am, "cr88192" <> wrote:
    > "BartC" <> wrote in message
    >
    > news:Ha5Xl.39495$...
    >
    >
    >
    > > "kid joe" <> wrote in message
    > >news:h0ig9p$nqn$...
    > >> On Sun, 07 Jun 2009 21:42:55 +0100, kid joe wrote:
    > >> <snip>

    >
    > >> Hi all,

    >
    > >> Id like to point out that the above message was a forgery not sent by
    > >> me.
    > >> I know that sound programming is OT here.

    >
    > > I was thinking of offering him this program to help him get started. I'm
    > > glad I didn't bother now.

    >
    > > #include <stdio.h>

    >
    > > int main(void){
    > > printf("\a");
    > > }

    >
    > would be ammusing though if there were an OS where one could do, for
    > example, midi via printf statements...
    >
    > all one has to do is embed each midi command into a form vaguely
    > resembling
    > ANSI codes (but with no timing info, so the app would have to implement
    > its
    > own time delays and send midi in real-time, or the delays would be
    > optional...).
    >
    > ok, going OT:
    >
    > (actually, I am almost tempted now to make a textual midi serialization...
    > unlike traditional midi it would be "human readable...", and potentially
    > even "human editable", and FWIW we need not care much if it is 2x-5x the
    > original size...).
    >
    > T8 C0,1 N0,39,127 T64 M0,39
    >
    > delay 8 ticks; program-change chan=0 to instrument=1; note-on chan=0,
    > note=39, vel=127;
    > delay 64 ticks; note-off chan=0, note=39, vel=127 (default value here).
    >
    > or, in summary: play a 440Hz note on a piano, with the whole sequence
    > taking
    > 0.6s (default: rate=120, q_note=1s).
    >
    > a more verbose notation could be easier to follow (for example, command
    > nmonics in place of letters), but could make sequences intollerably long,
    > and a learning curve of associating letters with commands may-well be
    > reasonable (after all, whoever would still have to deal with the "rest" of
    > midi terribleness...).
    >
    > or such...
    >


    <
    I wrote a midi "compiler" years ago to generate .mid files (too cheap
    to buy a drum machine). It read a line-oriented sequence of notes,
    that was something like this:
    <measure>.<beat> <note> <duration>
    1.1 A4 .4
    1.2 C5 .3
    1.3 E5 .2
    1.4 A5 .1

    Using the duration number, it would add the corresponding note-off
    later. IIRC, the midi file format requires a sequence number for
    each event, so "compiling" amounted to simply sorting the entries
    by number.

    But note-by-note quickly became tedious, so it eventually got a
    macro-processor, too. It's safely on a dead disk that I've yet
    get looked at.
    >


    I wrote a midi synth a few months ago (takes midi, produces waveform...).

    my idea was to make a more-or-less textual transcription of the MIDI opcode
    stream (although I would change delays into commands). this way, I would
    have the full capabilities of the synth at-hand.

    it is not clear if some "gloss" would be in-line here...


    --
    lxt
     
    cr88192, Jun 9, 2009
    #11
  12. kid joe

    luserXtrog Guest

    On Jun 9, 2:00 am, "cr88192" <> wrote:
    > "luserXtrog" <> wrote in message
    >

    [overdue snippage]
    >
    >
    > I wrote a midi synth a few months ago (takes midi, produces waveform...).
    >
    > my idea was to make a more-or-less textual transcription of the MIDI opcode
    > stream (although I would change delays into commands). this way, I would
    > have the full capabilities of the synth at-hand.


    That sounds cool. But hopefully you'll have some niceties
    like refering to notes by name, velocities by dynamic
    (pp,p,mp,mf,f,ff), and those variable-length numbers.

    > it is not clear if some "gloss" would be in-line here...


    I don't understand that fragment. Do you mean we shouldn't
    hijack this thread for midi stuff? Do you mean my post
    should have led-in to boasting about some old program
    with some sort of segue? Do you mean the glissando effect
    could be dealt with via some sort of macro-expansion?

    --
    lxt
     
    luserXtrog, Jun 9, 2009
    #12
  13. kid joe

    cr88192 Guest

    "luserXtrog" <> wrote in message
    news:...
    On Jun 9, 2:00 am, "cr88192" <> wrote:
    > "luserXtrog" <> wrote in message
    >

    [overdue snippage]
    >
    >
    > I wrote a midi synth a few months ago (takes midi, produces waveform...).
    >
    > my idea was to make a more-or-less textual transcription of the MIDI
    > opcode
    > stream (although I would change delays into commands). this way, I would
    > have the full capabilities of the synth at-hand.


    <
    That sounds cool. But hopefully you'll have some niceties
    like refering to notes by name, velocities by dynamic
    (pp,p,mp,mf,f,ff), and those variable-length numbers.
    >


    > it is not clear if some "gloss" would be in-line here...


    <
    I don't understand that fragment. Do you mean we shouldn't
    hijack this thread for midi stuff? Do you mean my post
    should have led-in to boasting about some old program
    with some sort of segue? Do you mean the glissando effect
    could be dealt with via some sort of macro-expansion?
    >


    this combines both points.
    by "gloss" I meant what you meant be "niceties"...

    basically, I am not sure if such niceties would be appropriate, but I guess
    some could be added...


    possible features being:
    note names;
    instrument names;
    ....

    so, one could type:
    "C0,synbass" vs "C0,38"

    but, doing this almost demands command nmonics, ...
    "PC 0,synbass NtOn 0,A4,127"

    and it is no longer clear exactly how far to go...


    but, then again, I guess it could also be argued that if tools were going to
    have to rely on lots of knowledge of MIDI, they may almost just as well
    craft the opcode stream manually, ... but, at the same time, lots of
    knowledge of MIDI would still be necessary, for example, to know how to
    operate the various controllers, ...

    as well, with so many names and nmonics, there could easily be a 10x-20x
    inflation vs the binary form, ...

    so, this is why my original idea had leaned more towards minimalism, mostly
    so it would be mostly intended for machine processing, and for limited human
    usage, rather than something aiming more for human readability... (none the
    less, it could still be read and written, even if possibly with the help of
    a few text-files containing tables...).

    in any case, it will still be far more readable than a hexdump, which would
    help with debugging, ... as well as being conviniently representable in C
    strings, easier to process and craft than the raw opcodes, ...

    as is, spaces will be optional...
    "C0,1T8N0,69,127T64M0,64"
    would do the same as:
    "C0,1 T8 N0,69,127 T64 M0,64"
    and the same as:
    "C 0,1 T 8 N 0,69,127 T 64 M 0,64"
    ....

    of course, I could use channel numbers 1-16 vs 0-15, so that at least
    channel 10 is percussion, vs 9...

    "C1,1T8N1,69,127T64M1,64"

    or such...


    --
    lxt
     
    cr88192, Jun 9, 2009
    #13
  14. kid joe

    luserXtrog Guest

    On Jun 9, 3:34 pm, "cr88192" <> wrote:
    > "luserXtrog" <> wrote in message
    >
    > news:...
    > On Jun 9, 2:00 am, "cr88192" <> wrote:
    >
    > > "luserXtrog" <> wrote in message

    >
    > [overdue snippage]
    >
    > > I wrote a midi synth a few months ago (takes midi, produces waveform...).

    >
    > > my idea was to make a more-or-less textual transcription of the MIDI
    > > opcode
    > > stream (although I would change delays into commands). this way, I would
    > > have the full capabilities of the synth at-hand.

    >
    > <
    > That sounds cool. But hopefully you'll have some niceties
    > like refering to notes by name, velocities by dynamic
    > (pp,p,mp,mf,f,ff), and those variable-length numbers.
    >
    >
    >
    > > it is not clear if some "gloss" would be in-line here...

    >
    > <
    > I don't understand that fragment. Do you mean we shouldn't
    > hijack this thread for midi stuff? Do you mean my post
    > should have led-in to boasting about some old program
    > with some sort of segue? Do you mean the glissando effect
    > could be dealt with via some sort of macro-expansion?
    >
    >
    >
    > this combines both points.
    > by "gloss" I meant what you meant be "niceties"...
    >
    > basically, I am not sure if such niceties would be appropriate, but I guess
    > some could be added...


    Perhaps two phases? Like an assembler and compiler. The niceties
    would work at a higher level (perhaps little more than macro
    expansion), and the assembler listing would use the thinnest
    set of mnemonics necessary not to require instrument numbers and
    "note on" to be looked up in order to read.

    > possible features being:
    > note names;
    > instrument names;
    > ...
    >
    > so, one could type:
    > "C0,synbass" vs "C0,38"
    >
    > but, doing this almost demands command nmonics, ...
    > "PC 0,synbass NtOn 0,A4,127"


    Not very hard with an enum, a char *[], and an X-macro.

    #define instruments \
    X(synbass) \
    X(guitar) \
    X(organ4)

    #define X(a) a,
    enum { instruments } einst;
    #undef X

    #define X(a) #a,
    char *sinst[] = { instruments };
    #undef X

    A for loop with strcmp to turn a string into an enum,
    and a simple indexing to turn the enum back to a string.
    Quick. Painless.

    > and it is no longer clear exactly how far to go...
    >
    > but, then again, I guess it could also be argued that if tools were going to
    > have to rely on lots of knowledge of MIDI, they may almost just as well
    > craft the opcode stream manually, ... but, at the same time, lots of
    > knowledge of MIDI would still be necessary, for example, to know how to
    > operate the various controllers, ...
    >
    > as well, with so many names and nmonics, there could easily be a 10x-20x
    > inflation vs the binary form, ...
    >
    > so, this is why my original idea had leaned more towards minimalism, mostly
    > so it would be mostly intended for machine processing, and for limited human
    > usage, rather than something aiming more for human readability... (none the
    > less, it could still be read and written, even if possibly with the help of
    > a few text-files containing tables...).
    >
    > in any case, it will still be far more readable than a hexdump, which would
    > help with debugging, ... as well as being conviniently representable in C
    > strings, easier to process and craft than the raw opcodes, ...


    Totally.

    > as is, spaces will be optional...
    > "C0,1T8N0,69,127T64M0,64"
    > would do the same as:
    > "C0,1 T8 N0,69,127 T64 M0,64"
    > and the same as:
    > "C 0,1  T 8  N 0,69,127  T 64  M 0,64"
    > ...


    All spaces are optional? That's a little wacko jacko. ;)


    > of course, I could use channel numbers 1-16 vs 0-15, so that at least
    > channel 10 is percussion, vs 9...


    It's nice when the interface uses the same terminology as the
    documentation. If a midi-knowledgeable non-programmer musician
    tried to use your system, I suspect (s)he would expect 10 rather
    than 9 to be drums.

    > "C1,1T8N1,69,127T64M1,64"
    >
    > or such...


    Niceties are nice; but I do agree that a barebones version
    would be much more flexible for the expert.

    --
    lyxdekcic
     
    luserXtrog, Jun 10, 2009
    #14
  15. kid joe

    cr88192 Guest

    "luserXtrog" <> wrote in message
    news:...
    On Jun 9, 3:34 pm, "cr88192" <> wrote:
    > "luserXtrog" <> wrote in message
    >
    > news:...
    > On Jun 9, 2:00 am, "cr88192" <> wrote:
    >
    > > "luserXtrog" <> wrote in message

    >
    > [overdue snippage]
    >
    > > I wrote a midi synth a few months ago (takes midi, produces
    > > waveform...).

    >
    > > my idea was to make a more-or-less textual transcription of the MIDI
    > > opcode
    > > stream (although I would change delays into commands). this way, I would
    > > have the full capabilities of the synth at-hand.

    >
    > <
    > That sounds cool. But hopefully you'll have some niceties
    > like refering to notes by name, velocities by dynamic
    > (pp,p,mp,mf,f,ff), and those variable-length numbers.
    >
    >
    >
    > > it is not clear if some "gloss" would be in-line here...

    >
    > <
    > I don't understand that fragment. Do you mean we shouldn't
    > hijack this thread for midi stuff? Do you mean my post
    > should have led-in to boasting about some old program
    > with some sort of segue? Do you mean the glissando effect
    > could be dealt with via some sort of macro-expansion?
    >
    >
    >
    > this combines both points.
    > by "gloss" I meant what you meant be "niceties"...
    >
    > basically, I am not sure if such niceties would be appropriate, but I
    > guess
    > some could be added...


    <
    Perhaps two phases? Like an assembler and compiler. The niceties
    would work at a higher level (perhaps little more than macro
    expansion), and the assembler listing would use the thinnest
    set of mnemonics necessary not to require instrument numbers and
    "note on" to be looked up in order to read.
    >


    yeah, maybe...

    yesterday, I got around to implementing part of the process (binary MIDI ->
    ASCII).
    on average, there seems to be about a 2.9x inflation...


    > possible features being:
    > note names;
    > instrument names;
    > ...
    >
    > so, one could type:
    > "C0,synbass" vs "C0,38"
    >
    > but, doing this almost demands command nmonics, ...
    > "PC 0,synbass NtOn 0,A4,127"


    <
    Not very hard with an enum, a char *[], and an X-macro.

    #define instruments \
    X(synbass) \
    X(guitar) \
    X(organ4)

    #define X(a) a,
    enum { instruments } einst;
    #undef X

    #define X(a) #a,
    char *sinst[] = { instruments };
    #undef X

    A for loop with strcmp to turn a string into an enum,
    and a simple indexing to turn the enum back to a string.
    Quick. Painless.
    >


    lookups are not too difficult...
    the issue though is that it would require more effort to parse the token.

    with raw numbers I can get by with a while loop:
    i=0; while((*s>='0') && (*s<='9'))i=i*10+((*s++)-'0');

    basically, I was designing a character-level syntax, rather than a
    tokenizing syntax...
    handling multiple token-types in a character-level syntax is a pain...


    > and it is no longer clear exactly how far to go...
    >
    > but, then again, I guess it could also be argued that if tools were going
    > to
    > have to rely on lots of knowledge of MIDI, they may almost just as well
    > craft the opcode stream manually, ... but, at the same time, lots of
    > knowledge of MIDI would still be necessary, for example, to know how to
    > operate the various controllers, ...
    >
    > as well, with so many names and nmonics, there could easily be a 10x-20x
    > inflation vs the binary form, ...
    >
    > so, this is why my original idea had leaned more towards minimalism,
    > mostly
    > so it would be mostly intended for machine processing, and for limited
    > human
    > usage, rather than something aiming more for human readability... (none
    > the
    > less, it could still be read and written, even if possibly with the help
    > of
    > a few text-files containing tables...).
    >
    > in any case, it will still be far more readable than a hexdump, which
    > would
    > help with debugging, ... as well as being conviniently representable in C
    > strings, easier to process and craft than the raw opcodes, ...


    <
    Totally.
    >

    yep...

    I had noticed though that, since my single-letter nmonics (A,B,C,D,E) are
    mapped 1:1 with the hex values, in many cases the prefix of many commands
    ends up resembling the hex version...

    > as is, spaces will be optional...
    > "C0,1T8N0,69,127T64M0,64"
    > would do the same as:
    > "C0,1 T8 N0,69,127 T64 M0,64"
    > and the same as:
    > "C 0,1 T 8 N 0,69,127 T 64 M 0,64"
    > ...


    <
    All spaces are optional? That's a little wacko jacko. ;)
    >


    the spaces are optional, since to parse them I insert periodic
    whitespace-eating loops.
    as noted, this is a char-level syntax rather than a tokenizing one.

    similarly, for many tasks we don't really need the spaces anyways...


    > of course, I could use channel numbers 1-16 vs 0-15, so that at least
    > channel 10 is percussion, vs 9...


    <
    It's nice when the interface uses the same terminology as the
    documentation. If a midi-knowledgeable non-programmer musician
    tried to use your system, I suspect (s)he would expect 10 rather
    than 9 to be drums.
    >


    maybe, I hadn't really that much considered human-produced data to be all
    that important...

    most data then would likely come either from prior-transcribed binary midi,
    or from procedural generation (such as "drum machine" loops, ...).

    of course, for procedural generation, support for absolute timecodes (and
    the ability to have events out of order) would be convinient, but supporting
    this would require a much more complex process to transcribe into binary
    midi.

    it is much simpler to produce multiple flat streams and then to merge them
    later (I already have the logic for this for binary midi, for text midi
    likely I would just convert to binary and merge this way, and then probably
    convert back to ASCII...).

    another possible approach could be to support such an ASCII form as well as
    the binary form for driving the synth, but for now this is not needed (I can
    convert to binary easily enough before sending it into the synth...).


    > "C1,1T8N1,69,127T64M1,64"
    >
    > or such...


    <
    Niceties are nice; but I do agree that a barebones version
    would be much more flexible for the expert.
    >


    yep, as well as being fast...

    I am actually designing the notation more for machines than for humans, the
    textual form is mostly to make inspecting data easier, and also making it a
    little less effort to craft the data (vs the binary form where one has to
    worry about a lot of little detail things...).

    but, the "textual" aspect is more a sideband aspect...


    FWIW, I actually before designed a bytecode/interpreter which worked this
    way (for GP tasks), where the bytecode was represented in ASCII, and so
    could thus be displayed via printf. internally though, it was structured
    much like any other simplistic interpreter.

    it is also similar to how I often manage "signature strings", where the
    ASCII form is cannonical (there is no binary form), but most of the code
    which handles them is based around loops and switches, and performs
    similarly to if it were a binary representation. (note that sig strings do
    not allow any whitespace, every character is meaningful and itself drives
    the logic...).

    so, ASCII need not be token based and slow...
     
    cr88192, Jun 10, 2009
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matt
    Replies:
    35
    Views:
    10,629
    George Neuner
    Jul 22, 2004
  2. Luc The Perverse

    Sound Quality In Sound API

    Luc The Perverse, Oct 30, 2005, in forum: Java
    Replies:
    4
    Views:
    1,489
    Andrew Thompson
    Oct 31, 2005
  3. Replies:
    0
    Views:
    507
  4. Replies:
    2
    Views:
    335
    Roedy Green
    Mar 9, 2006
  5. Mathias Goldau

    need an advise: Graphic & Sound Programming

    Mathias Goldau, Sep 9, 2003, in forum: C Programming
    Replies:
    1
    Views:
    546
    Richard Bos
    Sep 9, 2003
Loading...

Share This Page