Subject: Re: [linux-audio-dev] acid, linux
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe joulu 03 1999 - 08:18:37 EST
>On the surface, it will be still UG model, so every normal user can draw
>flow graphs, using simple modules "real programmers" wrote. So you write
>a sine oscillator, add module, multiply module, triangle oscillator and
>some filters. People can then build their synthstrings themselves, without
>knowing anything about how these modules actually work (let alone IDLs).
i don't think that people want to draw flow graphs. flow graphs are a
programmers conception. people want to create interconnections between
elements. as i am all too painfully aware, the flow graph is *not* the
same as the interconnections they create. its very closely related, of
course.
i don't see a UG model in aRts. your "modules" are fairly complex
units. they correspond more closely to Csound instruments than to
Csound opcodes, which are the real heart of a UG system.
>When the UG model was developed, the normal "academic way" to make music
>was to write a piece of music in your text editor, describe the instruments
>also in a text editor (using these nice opcodes). Then you would put your
>computer to work, and after 20 hours of calculation, you would hear the
>result. Compiler like music creation. Like LaTeX for writing books.
>
>But today, people want something that is interactive at every point, greatly
>integrated with the GUI, easy to understand (at least first steps) even if
>you have no clue about anything, visually attractive, etc.
>
>When people are using AudioLogic or CuBase and these various Plugins,
>Softsynths and whatever, they get a lot more of what they expect than
>if they are using CSound and Emacs.
i agree absolutely - how could i have ever written quasimodo if i
didn't ? :) but i think we should be leveraging from the accumulated
wisdom, source code and design skills that have come with the
evolution of those systems. quasimodo was an attempt to prove that this
could be done: take the UG's (opcodes) from Csound but let people use
them as in a Pulsar/Nord Modular/Kyma kind of way.
>Note however the relationship between the modules (or if you like) opcodes
>needs to be formally defined in any case for useful editing, and using the
>same formal definitions for "opcodes" and "widgets" - which happen to be
>something similar in aRts - seemed to be a good idea.
i think i might need to clarify something. In quasimodo, modules and
opcodes are very different. the relationship is like this:
a Module is an object containing a ProgramTemplate.
a ProgramTemplate is essentially a position-independent
representation of a Program - all pointer references
to Module-specific data are relative to some starting point.
a Program is an instantiation of a ProgramTemplate, and
consists of 2 linked list of pointers to functions, one
of which is executed when the Program is started, and one
whenever the DSP engine executes this particular Program.
the linked list of pointers to functions point to opcode functions.
a Process is an object that contains a Program, and a memory
allocation for the data used by the Program. A Process is
created by taking a Module object, allocating memory for
the Module-local data, then doing run-time editing on a copy of
the ProgramTemplate to fix up all the relative addresses.
The result is an object that can be handed to the DSP object
for initialization and execution.
a ModuleDefinition is an object that represents (part) of a file that
defines a Module. it can written in a variety of languages,
currently just Csound's orchestra language. Typically, a
ModuleDefinition uses opcodes combined with flow control
statements, relational, logical and arithmetic operators
etc. to define the desired operation of the Module. It may
also contain a definition of a user interface for the Module,
but this is completely independent of the definition of the
Module's operation.
>Thanks! ;) We could also try hard to reach interoperability between
>aRts and Quasimodo (that could be an even more valuable goal for the
>new year than throwing out midi of the respective core's ;),
good goal, but this might be easier said than done !
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST