Qua 1.0 (AA:PR)

What is Qua? Is it a midi sequencer? A midi patcher? An application sequencer? A brand of illicit psychedelic? An algorithmic composition system? A wierd and funky virtual instrument? The sound that ducks make? There is a very good chance that it is all of those things and more...

The Fundamentals of Qua

Qua began as astandalone algorithmic composition, running on an Atari ST. Hey some of the ST code is still there! It migrated to a Falcon, where it became a bit more generic, and was used to mangle The Quartet for The End Of Time into tabla patterns. This composition then evolved into a much more generic system, and landed onto BeOS, fertile soil indeed, where it mutated severely, under the influence of _unmentionables_ and thundering doof. Somewhere along the line there was an idea about turning poems about water into music, and this has left me with a bit of wierd terminology, and some very wierd memories.

It is a sequencer for midi data, application messages, and programs, called voices, written in its own script language, QuaScript. It also has a crossbar switching system that can route (performing appropriate data conversions) from any of these types of things to any other. Each of these objects has a crude graphic control panel, allowing them to be played and manipulated in pre-determined ways. It offers facilities for offline and online (as soon as full PR appears) editting of stored forms of this data. It allows for dynamic midi filtering.

Getting Started

Qua has a mime type of "application/x-vnd.DataSinkBeserker-Qua". This should be set in the distributed binary, but if it's not, the app may not run, and the mime type needs be set manually.

Clicking on the duck foot icon will bring up two windows:

Next step: bring up a sequencer page, through the main menu. Qua assumes that all reaonably interesting apps have an APPI structure attached somewhere. If a file doesn't have one, it will be assumed to be a savefile, if it has a header, otherwise it will be treated as an ascii text file, and parsed appropriately.

The sequencer page will come up with:

Press Go to start and Stop to stop. Overdub does nothing, as record presently records into new pools always. And there's no easy way to edit names. Record starts recording from all selected channels, and pressed twice, activates subsequent channels.

Control Panels

These provide a common interface to pools, apps, channels and voices, with a slight variation in accessible buttons as appropriate. They are generated from the lexical structure of voices, and automatically for everything else. The top set of button refers to the object itself usually, and subviews below correspond to sub-parts, either static function calls or preset blocks: These subsections are generlly, and since dr8, unfortunately, termed nodes.

QuaScript

The QuaScript language is a dataflow language which gives access to almost every aspect of the running sequencer to a source or voice. It maintains several types which can be accessed implicitly, particularly the stream and the items in it, and their fields, and the following explicit objects:

The standard format for defines is clunky but workable:
define # {# } []
Available modifiers are:

There are three kinds of lists:

Expression syntax is standard C, with sin,cos,tan,acos,asin,atan,exp,log,pow defined and available. The comma is used as a seperator, and is only used to disambiguate messy stuff for the parser. Time is measured in clocks generally. Currently things are fixed at 12 clocks to the beat. Booleans are only evaluated when a sequence is complete. Statements include:

  • assignment. standard, but if the lval refers to a stream item, the rval is performed for every element of the stream. e.g. pitch = pitch + 10
    transposes every stream element passed through it.
  • call of a source.
  • constructor:
    • tone(,,): a noteon/noteoff pair
    • ctrl(,): midi ctrl
    • sysx(): sysx, dumping the fields of the source/node into a sysx message
    • prog(): prog change
    • bend(,): pitch bend
    • mesg(,{,}, ...): construct a BMessage
  • The scheduling operator, <- which executes the block once, and then reschedules itself for execution when the stream prroduced by the block is completed.
  • The scheduling operator, <-() which executes the block once, and then reschedules itself for execution after the number of clocks given by expression.
  • wait(): halts execution of the list until exp is true.
  • << : input from channel
  • >> : output to channel
  • ::: do block if is trus
  • if ()else: do block if is trus else do block2
  • with ()else: do on items matchingelse put them through
  • ::: do block if is trus
  • kill : signal voice
  • wake : signal voice
  • suspend : signal voice The system provides lots of nice variables, most usefully:
    • self; the voice itself
    • pitch: field for a tone
    • dynamic: field for a tone
    • duration: field for a tone
    • bar: current bar #
    • beat: curtrent beat in the bar
    • clock: current subdivision of the beat
    • actualtime: in sec
    • clocktime: total # of sequencer clocks(i.e. pulses)
    Other useful predefs include 2nd order markov chains, illustrated in piano_inst, and pool manipulation functions (r08_inst) (partly broken but back soon),

    This has probably confused the hell out of you, but listen and look at the provided test patches. The "r08_inst", drum map editor is currently broken, but contains some good examples of twisted but useful coding. The rest should be OK, but are set up for EPS percussion and kit instruments. The afro_instrument is quite pretty on piano.

    Known Bugs and Frailties

    The list is manifold, but here it is so far:

    • The parser does not recover from errors at all well. At some stage, I'll redo it in yacc/bison, and the situation should improve. A lot of this stuff had its birth on an Atari ST: need I say more? In particular, paramater count mismatches on builtins may segfault.
    • Objects should be properly deletable from the aquarium.
    • The save file situation is flaky, will improve under testing, and will likely change in format slightly as time progresses. There is enough information in the header to find out when something was saved, and how it could be converted. Qua will probably do this automatically if anybody thinks this is a good idea.
    • Child processes get orphaned, and have to be killed with something like TManager. I haven't had time to work out why, but I think it's something simple.

    The Future of Qua

    Lot's of stuff in the pipeline, particularly now that system APIs have settled:

    • The on-line stream editor (i.e. the interactive beast you would expect) will reappear very soon. It existed in the past, but relied on the dr8 3dKit (which will go down now in memory as one of the Great APIs I Have Known Through Ritualistic Examation Of Header Files).
    • A graphic editor for QuaScript. This is also slated fairly soon. Personally, I prefer ascii text, which is a nice scoring tool for _some things_ and not others. I'm not overly fond of MAX's, but it will look interesting, and let mods be done to running scripts on the fly.
    • Multiple meters, polyrhythms, tempos and other wierd timegrid overlays. Synchronizing multiple clocks is already done internally, but simplicity of the interface has suggested the 4-to-the floor, 12 subdivision to the beat approach. Anyway, most people can't dance to 7:5.
    • Import and export of general midi files. This is high priority.
    • Loadable addons for QuaScript. This is a bloody good, almost essential, idea, that I just haven't gotten around to.
    • Loadable addons for The ControlPanel interface class. Another cutie, but a bit messy, as it's a very twisted thing that gets used in lots of wierd ways.

    Thanks and Acknowledgements

    I would particularly like to thank: Tamara Verhagen, for support above and beyond the call of romance, and for maintaing my sanity when I didn't think it would hold out; Alistair Riddell, for support, belief, and a sound ear; the manufacturers of Daffy Ducks; Adrian Sherriff, and Andrew Gannon; Olivier Messiaen, whose quartet I've enjoyed mauling; Micheal Pallot, for a gracious loan of an Atari Falcon (on which this morass was begun); anybody and everybody else whose names I've forgotten because I was too drunk at the time.

    Contact Point

    Information on Qua, rack303, and other fabulous DataSink Beserker products (soon to be announced) can be had from me at:

    dak@zog.net.au

    dak@cs.latrobe.edu.au

    David Karla
    29 Rushall cres,
    North Fitzroy,
    Melbourne, Australia, 3065.

    I'm keen to here what people do with this beast, and I'm eager for bug reports and suggestions.
    Nano nano,

    Dak, 25/7/97
    .