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...
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
Perhaps it would be good if those were sgml or html or something that everyone can view.
Same direction as the documentation. People need to see that it's really a capable program!
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.
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.
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.
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 ;)
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 ;)
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:
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.
There might be something else ... see section midibus/other considerations.
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.
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
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. ;)
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.
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.
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.
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:
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.
Think about it.
These coding styles are late, I know ;), I started without them. Anyway, in the future, try to stick to them.
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 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.
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 are always uncapitalized.
Local variables are always uncapitalized, and may have names like i, p, x, etc. where appropriate.
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?
// 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");
Call Synthesizer->createStructureDesc(). You'll get a structure description.
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.
Modules should look like that:
---- --------------- | ic | A B C | | on |label a | ---- --------------- | | | | |
Modules should be positioned by the GUI to be non-overlapping.
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
Use Synthesizer->createStructure(StructureDesc) to create an instance of that structure, that will be synthesized.
Keep the id and pass it to freeStructure later.
Save your StructureDesc with saveToList(), and write the contents of the resulting Arts::StringSeq to a text file. Give it the extension .arts
Load an arts file into an Arts::StringSeq. Go to a StructureDesc you have already and call StructureDesc->loadFromList(theStringSeq).
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.
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