Specimen is a midi controlled sampler, and it's very first public
release is available from http://www.gazuga.net/specimen.tar.gz
In all honesty, I advise against downloading this in it's current
state unless you intend to hack on it or play with it for sheer
amusement value only. There are a few TODO items that must be taken
care of before this can be considered usable software (as the next
release will be). The main reason for this release is because I said
I was going to make a release in a couple of weeks 15 days ago.
It's very nascent stuff.
You have been warned.
[pb]
7 pages with written by Albert Veli
Take a look at the front page :-)
http://www.datormagazin.se/ssjs/aktuellt_nr.html
It mentions, with varying levels of detail:
* Alsa (three pages)
* GNOME ALSA Mixer (with screen dump?
- it look old and boring compared to KMix in KDE 3.2 IMHO)
* Jack
* Qjackctl (with screen capture?)
* Fluidsynt
* Timidity++
* LADSPA
* Jack-rack
* Ecamegapedal (with screen capture)
* Rosegarden-4 (with screen capture)
* ReZound (with screen capture)
* Muse
* Audacity
* Ardour ["problematic to compile, steep learning curve" the article
suggests looking at www.djcj.org/LAU/quicktoots
* Ecasound
* AlsaModularSynth
* Legasynth
* SpiralSynth
* Pd
* Soundtracker, cheesetracker
* Alsaplayer
* xmms
/RogerL
--
Roger Larsson
Skellefteå
Sweden
>From: Benno Senoner <sbenno(a)gardena.net>
>
>the method I use to communicate between the GUIs is SYSV message queues
>because they can be multiclient but the API is abstracted so the
>underlying transport model can be chosen arbitrarily.
I have written and I'm writing a message system where client sends,
e.g., the following msg to the server:
read <file id> <loc> <len> <addr> <return value>
which reads a block of audio from a file to a (shared) memory
location.
I did not see the return value in your system (and don't figure
out how one goes without it). The server sends both the result
and the given return value back to the client. The return value
could be something which only the client knows, e.g., array
index, memory address, text. Something which associates the
result with the request.
The implementation is too complex to my taste as the messages
are combination of raw byte data and string data. Each message
starts with <int> which tells the length of the message. I have
written a set of routines to assemble and disassemble these
messages. I send these messages via pipes/sockets, via shared
memory, and whatever.
In any case, such message system should be general enough,
and the return value brings it to that direction.
Hmm... what do you mean by multiclient? Is the writing to the
message queue an "atomic" operation for long messages?
I use one pipe/socket per client to one server because I suspect
only the server can make the long messages "atomic" by interleaving
them correctly. Likewise, I use one lock-free shared-memory FIFO
per client to one server.
Regards,
Juhana
Have you seen this?
http://faac.sourceforge.net/
I was browsing sourceforge, and found this, it might be of interest to some
people on this list.
-Richard
Inspired by the Vocaloid thread, an old idea sprung back to mind;
retro "chip style" speech synthesis.
Is there a simple, minimalistic, Free/Open Source phoneme-to-audio
synthesiser out there? I'm not terribly interested in the
text-to-phonemes part and other higher level stuff, as I intend to
use this for sound effects in games and (other) toys. Doesn't hurt if
CPU and memory requirements are very low, but I'm probably going to
render words and phrases off-line anyway (at install or load time),
for later processing as normal sound effects.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
On Thursday 20 November 2003 01:09, Paul Davis wrote:
> http://news.harmony-central.com/Newp/2003/Vocaloid.html
You know, FESTIVAL (the popular and quite good opensource speech synthesis
package) has a mode where you can feed it data to sing.
It could probably not be very hard to write a similar GUI where
you edit a pianoroll to make festival sing.
Seems like a very nice small project, anyone willing to take it?
Juan Linietsky
This from the csound list. Dr. Boulanger at Berklee has indicated that
he is also working on a csound course to be posted there.
--
Hans Fugal | De gustibus non disputandum est.
http://hans.fugal.net/ | Debian, vim, mutt, ruby, text, gpg
http://gdmxml.fugal.net/ | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
On Sunday 23 November 2003 09:07, Luke Yelavich wrote:
> At 08:56 PM 24/11/2003, Juan Linietsky wrote:
> >On Thursday 20 November 2003 01:09, Paul Davis wrote:
> > > http://news.harmony-central.com/Newp/2003/Vocaloid.html
> >
> >You know, FESTIVAL (the popular and quite good opensource speech synthesis
> >package) has a mode where you can feed it data to sing.
> >It could probably not be very hard to write a similar GUI where
> >you edit a pianoroll to make festival sing.
>
> There is a much better speech synthesizer, known as DECtalk which can sing
> quite well, and it is very easy to programme. The nicer thing is, it is
> available for Linux as well! I have it here, so I will did up a text file,
> and post the resulting OGG if anybody is interested :)
As far as I know, dectalk is commercial, isnt it?
Juan Linietsky