
 
general information
main page
history
mailing-lists
related links
contact us
our sponsors
arts online
download
screenshots
demosongs
aRts mirror-sites
mailing-archive
documentation
aRts manual
aRts - the 1st year
call 4 aRtists!
aRts/MCOP docu
 
v:1.5

|
|
aRts - analog realtime synthesizer: Development
Next
Previous
Table of Contents
[ Don't ask what aRts can do for you, but what you can do for aRts ;) ]
Perhaps you would like to help to make aRts even better, but you don't
have an idea what is needed. It might be that you don't have skills in
C++ or Qt-programming, or whatever.
First of all: subscribe the mailing list; look at
http://linux.twc.de/arts
for details. The tasklist in this documentation may not always be up to date.
I have created a list of tasks that I think are important for the
project to evolve fast. If you like, pick a task that interests you
and contact me...
Tasks which do not require programming skills
- Perhaps more general documentation about synthesis
It would be great to have some (possibly illustrated) documentation/
tutorials that actually describe more about the various kinds of
synthesis, about effects, about instruments.
Just to name a few, I think most people who want to learn using
arts need more introduction about
- What is frequency modulation?
- What is ring modulation?
- How do oscillators work?
- What do these filters do?
- How can I create a vocoder?
- How can I create a nice analog sound?
- How work old style synthesizers like the 303, 909, mini moog, ...?
- How to do all that with aRts?
Perhaps it would be good if those were sgml or html or something
that everyone can view.
- Examples for aRts
Same direction as the documentation. People need to see that it's
really a capable program!
- Demosongs
If you have created something great, just contact us ;) There should
grow a collection of mp3s on the arts homepage, so that people can
judge from listening what it is like to use aRts.
- Structure maintainance (important!)
As aRts slowly grows up, it will reach its goal that virtually every
synthesizer, studio device and effect can be built out of small aRts
modules.
But this also means that somebody should maintain a set of standard
structures that ship with the aRts distribution, such as mixers,
equalizers, synthesizers, effects, control panels, desktop aids,
what ever. Like the most important part of emacs today probably isn't
the basic code, but all the emacs-lisp things shipped with emacs (from
syntax highlightening to the dunnet dungeon and other games), a
significant amount of usability for the end user will depend on a
large set of structures that ship with aRts.
- Module normalization
This one is quite a large task. But certainly interesting as well
as challenging.
The point is: we have about thirty modules now. We'll need perhaps
fifty or houndred or so, for the thing to be really useful. These
have to be categorized and sorted, described and written.
What is specially important is that they follow the same concept.
For instance it makes no sense, if some modules require frequencies
to be specified as 1/f, others need them to be given as f.
It will help for that task if you can write own modules (you only need
a little C++), but it is certainly not required.
A good starting point would perhaps be to create a naming hierarchy,
where all modules could be sorted in, such as Synth_BUS_UPLINK =>
Synthesis/Busses/Uplink or Synth_SHELVE_CUTOFF =>
Synthesis/Filters/Shelve Cutoff. The module names are kind of
hierarchical, but since they may never be changed another hierarchy
would probably be a good idea (since this would also allow us to
translate this hierarchy in internationalized versions).
All those modules that are unstructured such as Synth_PLAY or Synth_MUL
or Synth_CDELAY should find a place in the hierarchy as well.
tasks which do require programming/scripting skills
- plugins
Think about how the GUI and the synthesis system could be extended at
runtime with dynamically loading plugins. There is something in
koffice2, don't know if it's usable for that though.
Specifically for the synthesizer we can't afford performance loss
while scheduling ;)
- midi bus: general
How can Arts and the rest of the world communicate? How can the
midi events be routed? Ok, there is a lightweight solution, but
this is not good when you have ten "devices" on your midi bus.
Not yet. In any case this has to be discussed in public (on the
corresponding kde lists), to get things compatible later.
Anyway it would be great if more programs (beside Cantor) started
supporting the midi bus stuff. Perhaps some trackers (voodoo tracker,
soundtracker, kegtracker), some other sequencers (jazz, koobase,
gseq, whatever else)
BTW: I will not focus on making Arts (and the midi bus and the like)
a KDE only project, but writing a KDE gui was the fastest way for me
to get things really working and usable. I want to MAKE MUSIC with
that stuff soon and not design around two years ;)
- midi bus: tuning
The midi bus sound sluggish when under high load (a thousand events
per second). That's not nice. I think, it would be possible to solve
that problem entierly when there would be a standard how to pass
events though the bus non realtimed. It could work something like that:
- Client program asks server to open a channel
- Client program puts in the events for the first ten seconds
(with time stamps)
- Client program says start to the server
- Server notifies client program when it needs more events
or
- Client programm polls song position
- Client programm fills in more events when needed
Since transferring multiple events in a sequence should be much much
faster than transferring only one event at a time, we should be able
to stick to CORBA.
Another option would be to transfer the events using TCP sockets, UDP
or IPC sharedmem. All of these will be faster than CORBA.
- midi bus: no midibus
There might be something else ... see section midibus/other
considerations.
- gui builder
This is a challenging part as well. We need something that shows whats
going on - and of course all those buttons where one can tune around
to modify the sound. Perhaps we can reuse something from koffice here
as well, to get "components", which simply can be plugged in runtime.
Well there is some stuff running now, but of course lots of room for
improvements.
- performance tuning
Everything that makes things go faster is welcome. You'll need to
experiment, profile and think a little here.
Arts is already a lot faster starting at version 0.3.0 due to multisample
calculation.
BTW: multi CPU support (SMP) would be nice
- module writing
This is close to the module normalization (see above). We need that...
now, because without modules which are cool and work together like a
dream Arts has no value.
You will only need a little knowledge about how to program (C or C++),
since modules which mix two sampling streams or delay audio data tend to
be simple. ;)
- reading sample cds
Certainly synthesis is not the ideal way to achieve everything. If you
want a Steinway, you should perhaps buy one as samples and use it. It
would be great if aRts simply could read sample cds in common formats,
such as AKAI - it would make composing with aRts really easier. Its
so much less work to use a complete sampled piano with velocity switches
than to configure them by hand in dialogs.
Mostly solved.
- flowsystem: event passing
It would be nice if the flow system of aRts could not only process
signals but also events. This would mean you could have modules which
transpose/combine/modify/filter midi streams just as you have modules
which do the same for signals.
- audioserver
I personally think it would be a good idea to make aRts capable of
replacing esd and kaudioserver and nas and whatnot in the future. aRts
should become a mix of DirectX and DirectShow, Generator and the
CuBase VST/Logic audio subsystem.
Anyway this makes it necessary to work on integration with others and
to make sure that aRts actually can handle all tasks that are currently
handled by classic audio servers as well.
- higher level structure composition
Assume the following problem: you want to describe an abstract mixer.
A mixer has a number of channels, and a number of effects. On each
channel, you have preamplifier, then an equalizer. Then, a certain
amount of the signal is routed though the different effect processors
(including one zero effect processors, which means play directly).
It should be possible to describe the abstract mixer in aRts, then
the effects (delay, reverb, chorus,...) and then the instruments
(piano, drumset, strings,...)
After that these stuff should be put to some kind of structure database.
Finally the end user should only need to do the following:
- Start his sequencing software
- Say: mmm - I want a mixer
- Select one from the list
- Have some buttons to add & remove channels
- Set the number of channels to 4
- Load some effects (delay, reverb, chorus and none)
- Load some instruments (piano, drumset, strings)
- Assign the instruments to the channels
- Use the mixer to calibrate the channels
- Use the panels for the effects to configure them
- Start to compose
Structures which can be used as modules (as in 0.3.1) probably solve
parts of that, but they are not really a complete concept. There has
been some work on that issue, but more is probably required.
For instance, the fact that there is an example_mixer_simple,
example_mixer_eqfx, example_mixer_eq, example_mixer_eqfx8, ...
should make you think. Why that many? And why are the channel
counts hardcoded. There should be a more modular way to solve
that especially as soon as more effects come up.
Think about it.
- power saving architecture
Arts shouldn't consume CPU power while nothing is calculated - this
may involve significant changes in the scheduler to make that work.
- common server implementation
The GUI and Flow server should share more of their implementation -
perfect would be if they used common plugins as well.
- new transfer architecture
Transfer between GUI and synthesis server over CORBA is a bad idea
as soon as the number of events increases. A new transfer middleware
needs to be written, for instance to be able to support scopes in
a CPU saving way.
Using sharedmem or TCP would be probably a good idea.
- small tasks (how do I spend this afternoon)
- Synth_WAVE_TRI should be called Synth_WAVE_SAW, and the
Synth_WAVE_TRI should be reimplemented like on all other synthesizers.
Change the examples for that.
- Synth_WAVE_PULSE should be a SQUARE wave with configurable up/down
time. Make examples.
- Using a structure called "foo" inside a structure "foo", and
executing the result gives a crash.
- Consider writing a module which directly reads /dev/midi (not
via midisend). => better timing.
- Wave file pitchshifting (implement like in the AKAI modules,
perhaps more common code to convert.cc).
- Redo directory structure (if you like to do that, ask before).
Modules should be seperate.
- Add splash screen loading code instead of that ugly "should
I start the server now" message box. Contact Harald for graphics.
- Try to integrate soundfont support in an intelligent way - the
code is for instance available in timidity.
- Add native ALSA support.
- Implement progressive sample loading, which may result in much
better performance on the first playing of a sample.
- Eliminate Interface_MIDI_NOTE and replace it by standard ports
(eventually complicated).
- Instruments that require a filename should be able to have a
control panel where you can enter that (eventually complicated)
- Every module should have an own file (related: dir structure cleanup)
- Modules should be shared libraries
- Avoid calling kvt if no kvt is there (call something else like
xterm instead).
- Remove every Calculate and replace it by CalculateBlock - after
that, remove Calculate from SynthModule completely, and
haveCalculateBlock.
- Introduce kdoc
- Help buttons should do something (best thing would be to show
a help page, context sensitive).
These coding styles are late, I know ;), I started without them.
Anyway, in the future, try to stick to them.
- Naming of member functions
QT Style, that means capitalization on word breaks, and first letter
always without capitalization; no underscores.
This means for instance
createStructureDesc()
updateWidget();
start();
- Class members
Class members are not capitalized, such as menubar or button,
_but_ pointers referring to remote objects *are*, such as Synthesizer.
When there are accessing functions, the standard should be the CORBA
way, that is, when having an long member Foo, which shouldn't be
visible directly, you create
Foo(long new_value);
long Foo();
functions to get and set the value. In that case, the real value of
Foo should be stored in _Foo.
- Class names
All classes should be wordwise capitalized, that means ModuleView,
SynthModule. CORBA classes normally have a namespace, such as
Arts::Synthesizer.
The implementations of CORBA classes should get called Class_impl, such
as Synthesizer_impl.
- Parameters
Parameters are always uncapitalized.
- Local variables
Local variables are always uncapitalized, and may have names like i, p, x,
etc. where appropriate.
- Tab width (Shift width)
One tab is as long as 4 spaces.
The future of KDE (and other systems like GNOME) and their
interoperability highly depends on inter process communication.
Scripting, embedding, interoperability, comfort, reuse of existing
components, ... all depend on that. CORBA will be the way to go.
It provides all those features over network, cleaning up with all
dirty hacks and protocols, IPC-solutions and self-built-plugin-
solutions that have been there in the past.
Now the time has come where people (including me) must learn to
use these technologies, so that the evolution of even better software
can take place under free operating systems such as linux, in free
projects such as KDE, and so on.
So I started writing arts (a project which interests me since
not too short time) using CORBA. I will have to learn what we can
achieve with it, others will have to learn that, and CORBA must
get a tool just like a shell, C++, Qt or gtk, or anything else.
Of course there are problems right now, and your CORBA tools won't
have the widespread use and testing as for instance your shell has,
but its important to get there soon.
And - I'd really like to do MUSIC - I have no windows of whatever
since I do not accept to work with it at home, there are better
things to do ;)
So Arts will just be what I (and others I hope) need. A tool to
make music, a medium to learn CORBA & Co, a project which is fun,
and something that has - in contrast to some of those ugly
applications out there - a gui that is cool and can communicate
with other state-of-the-art applications.
Arts has a very flexible design. It is meant to be used from many
applications as synthesis server at the same time.
I am sure that some people don't like ArtsBuilder as well (which currently
runs under KDE). In fact, Arts has been designed to make porting that part
very simple, intending to have Gnome (or other) GUIs later.
While this guide mainly describes the interaction between ArtsBuilder and
the Arts synthesizer, it will be useful for making other simple or more
complex applications talk to Arts as well.
So, what you have to do in your GUI?
- Connecting the Synthesizer instance:
// You'll need to call orb->bind, mico code for that is:
CORBA::Object_var obj =
orb->bind ("IDL:Arts/Synthesizer:1.0", "inet:localhost:8888");
- Creating a Synthesis structure description
Call Synthesizer->createStructureDesc(). You'll get a structure description.
- Creating modules
Use Synthesizer->getModuleCount() and Synthesizer->getModuleInfo() to
obtain ModuleInfo records. They have a member name, which contains the
name of the module. Display that to the user, avoid using other information
(which is not guaranteed to remain in that record in further releases).
Go to your StructureDesc and pass it the module info, if you'd like to
create such a module description. This will be put in the structure.
You may now display it visually. You should move the module to a correct
location (moveTo(x,y)) before saving the Structure.
- Displaying modules
Modules should look like that:
This module would have input ports A B C, output port a, and be called
label. Thus, the module will have the height 1 in a grid scheme, and
the width=1+max(inports.size(),outports.size()+1).
Modules should be positioned by the GUI to be non-overlapping.
- Connecting ports, setting parameters
You can now set the parameters of your Module using the ModuleDesc->Ports
sequence, which contains references of the Ports a module has. You can
call connectTo, disconnect,...
A port can either get assigned a value or be connected, or remain unconnected
- Executing modules
Use Synthesizer->createStructure(StructureDesc) to create an instance of
that structure, that will be synthesized.
Keep the id and pass it to freeStructure later.
- Saving files
Save your StructureDesc with saveToList(), and write the contents of the
resulting Arts::StringSeq to a text file. Give it the extension .arts
- Loading files
Load an arts file into an Arts::StringSeq. Go to a StructureDesc you have
already and call StructureDesc->loadFromList(theStringSeq).
Of course Arts is still under design, fundamental things like building
GUIs for synthesizers are missing and not specified in the interface.
So, the Arts-Interface will grow further in the future. But I think if
we have at least two GUIs to improve that interoperability thing, it
will really help to make it a good solution.
Theoretically, you can port arts to other operating systems easily as
well. As long as mico compiles on the target platform, the synthesizer
should compile as well. You may need to change some code in Synth_PLAY,
but that's about it. Then you can create a new GUI using native tools
under your OS, or perhaps Java, and you have a port.
- Advanced features
Of course, aRts didn't stay that simple as described above. Perhaps the
most important news is, that you can have visual modules now. These are
implemented internally by having the GUI process provide an ArtsServer
CORBA interface, which can instantiate structures (just like the main
synthesis server). The idea is that the gui, too, should be composed
of the same modules and follow the same rules like the synthesis "play-
ground".
This makes porting harder, and suggests porting by simply taking the
whole artsbuilder and replace the Qt calls by Gtk-- calls (or whatever
else). Anyway, if you intend to do that, consider making it in a way
that it can be integrated in the main artsbuilder version, so that both
stay compatible.
If you want to go the other way (implementing an ArtsServer interface
isn't too hard either), make sure you coordinate the GUI interface, so
that structures understood by the Qt/KDE-Artsbuilder are also understood
by your replacement, and vice versa. Perhaps develop a cross component
model (for reusing visual components that work in ArtsBuilder in your
piece of software and vice versa).
Next
Previous
Table of Contents
|
|