Hi all ...
Sorry for the english ... like always ..
Well ... recently i'm working on export gmorgan songs sequences in a Standart
Midi File format ... hope this will be ready in a few days ... and working
with this .mid format ... i think is to hard.
I understand ... in july of 1984 when the manufacturers adopts this standart
maybe .mid was really useful ... saves lots of space etc etc ... i ignore the
future plans of manufacturers ... but ... seeing sequencer programs, obvius
each one uses their own file format to work, and can only export or import
midifiles.
I know ... linux comunity is small ... we can't change nothing of the
manufacturer plans, maybe all of this is crazy thing, but i really think we
need a Standart Audio-Midi-SMPTE File Format, on witch the programs can work.
Well i understand ... by now we need this protocols to comunicate with
external devices ... but each day the computers are more powerfull and ... i
read in the last days messages about syncronization of Muse with Ardour .. or
Hydrogen ... ALSA sequencer ... and we need to doit with a 1984 protocol?
Well you know me .. i'm a complete ignorant ... but i think we need something
who runs almost internally in the computer for do this things. Maybe the ALSA
guys want to do something about that? or i'm realyy crazy? :-)
Josep
Hi!
gmorgan is a .. Rhythm Station, an organ with auto-accompaniment and a "small"
Band in a Linux Box. Uses MIDI and the ALSA sequencer for play the rhythm
patterns. Styles, patterns , sounds, and the mixer settings, can be edited
and saved.
Program is released GNU/GPL version 2.
News on 0.04
--------------------
- New Song File format.
- Added New in Batch Play Menu.
- Added more markers in Batch File Play-Editor.
- Added New marker system salt in Batch File Play-Editor.
- Added Finish point for the entire song in Batch File Play-Editor.
- Added Export Midi Files in Batch File Play Editor.
Hope i create the midi files in a correct way, i checked with pmidi and
rosegarden4 and works fine, but still have some problems with muse.
REQUERIMENTS
--------------------------
Fast Computer
Linux
ALSA
Fltk
Take a look at http://personal.telefonica.terra.es/web/soudfontcombi/
And please ... if you enjoy this prog and wants to share patterns, send me,
and i will include in future versions, i have a large TODO, and i need some
help.
Josep
AFAIK, Debian stable (woody) includes wxGTK 2.2.9.
Stefan
>From: Dave Phillips <dlphilp(a)bright.net>
>Reply-To: linux-audio-dev(a)music.columbia.edu
>To: LAD Mail <linux-audio-dev(a)music.columbia.edu>, LAU Mail
><linux-audio-user(a)music.columbia.edu>
>Subject: [linux-audio-dev] wxWindows and Linux distros ?
>Date: Wed, 16 Jul 2003 11:33:10 -0400
>
>Greetings:
>
> I couldn't find the answer to this one on Google, so:
>
> Which Linux distributions include wxWindows in their default
>installations ?
>
>Best regards,
>
>== dp
http://www.linux-sound.org/rtsynth
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
>From: Jussi Laako <jussi.laako(a)pp.inet.fi>
>
>I haven't got any problems with shared memory,
My alsashmrec with two processes and a lock-free shared memory
buffer has worked fine for a few years. If I were not started
testing and rewriting the tools, I would not have figured out
any problems as well.
> but afterall, I don't use
>the SystemV method (shm* functions) because it sucks. I think the
>SystemV IPC stuff sucks as whole. I like to use the "real" POSIX way..
I would like to test with posix routines as well.
Can you mail me some example code? Plain ascii, no attachments.
If I would have a list of posix shm routines, I would read the
man pages, but then I did read systemv man pages as well, and that
did not help at all. :) Example code would be nice.
Best regards,
Juhana
>From: Ingo Oeser <ingo.oeser(a)informatik.tu-chemnitz.de>
>
>You have synchronisation problems. Shared memory means only that
>it's shared, not that it's synchronized for you. You either need
>to synchronize portably by hand using semaphores or use atomic
>operations.
No, my test indicates that the memory is not *the same* in the two
processes. If "shared memory" is something which is the same only
occasionally, then that is what I have now.
Semaphores or atomic operations has nothing to do with this problem.
>Or you have scheduling problems, if you are disturbed by the
>fact, that the client isn't getting the same amount of CPU as the
>server.
That is better explanation for the slow printing. The shmserver
may be too intensive. However, it is not an explanation for
why the shared memory is not *the same*.
But then, while shmserver was running and shmclient printing,
my simple painting program indicated no slowdowns in painting,
which involves a large brush with computations like sqrt() on
each pixel.
I remember this same problem appeared when I modified XWave
at 1998. The play process (X toolkits background process) wrote
the play line location and the GUI process read the location.
Now that did not involve any unlimited computations as the
processes were bound to D/A converter and to periodic update
of X toolkit.
>> Maybe 20 times per second with "renice 19". Slow.
>
>That's normal. They lock each other out for a whole timeslice,
>since they are CPU-bound. If you want them to schedule at certain
>events (e.g. after one of these computation cycles), you have to
>tell the kernel by using semaphores.
I don't understand. Can you explain how semaphores are used for that?
Best regards,
Juhana
Hallöchen!
Ich bin von der LUG Gießen. Ich möchte gerne anfragen,
ob es von den Audio-Freaks Interesse gibt, einen Stand
auf dem Practical Linux in Gießen zu machen, auch
ein Vortrag oder Workshop wäre nett. Wir haben
neben einer Ausstelung ein ganztägiges Vortragsprogramm
und ein Workshops.
Mehr Infos findet ihr auf www.pracitcal-linux.de
Wir würden freuen wenn das Proejkt bei uns vertreten wäre.
Bye Bye
Lars Stetten
Hi,
This is a message for those who speak spanish and are Linux audio and
MIDI users or developers, from wherever around the globe. Thanks and
sorry for cross-posting.
Free Tools es la primera comunidad en español dedicada a prestar soporte
al usuario y desarrollador de aplicaciones de audio y MIDI para el
sistema operativo Linux.
Todos los interesados en el tema están invitados. Para la suscripción,
de disponerse de cuenta abierta en Yahoo!, basta con visitar este enlace:
http://es.groups.yahoo.com/group/free-tools/
En caso contrario, es suficiente con enviar un mensaje de correo
electrónico en blanco a:
free-tools-subscribe(a)yahoogroups.com
Allí os esperamos.
Regards, Ismael
Hi!
gmorgan is a .. Rhythm Station, an organ with auto-accompaniment and a "small"
Band in a Linux Box. Uses MIDI and the ALSA sequencer for play the rhythm
patterns. Styles, patterns , sounds, and the mixer settings, can be edited
and saved.
Program released GNU/GPL version 2.
News on 0.03
--------------------
- New Drum Pattern Edit
- Added some "demo" patterns and songs.
- Lots of bugs solved.
REQUERIMENTS
--------------------------
Fast Computer
Linux
ALSA
Fltk
Take a look at http://personal.telefonica.terra.es/web/soudfontcombi/
And please ... if you enjoy this prog and wants to share patterns, send me,
and i will include in future versions, i have a large TODO, and i need some
help.
Josep
Hello. I examined further the shared memory malfunction.
Locking the memory with mlockall() did not help: the shared
memory is not updated in the client. I used mlockall() both in
shmserver and in shmclient.
For some reason the shared memory is not a true shared memory.
The shmserver and shmclient do have the shared memory segment
obtained with the same shmid value, but processes seems to
have their own duplicates of it. I have no other explanation.
These duplicates were updated when the shmclient performed sleep(1).
Now I have non-waiting sched_yield() in the shmclient, and that helps.
shmserver is very computation intensive process: it goes through
the whole shared memory and increases the integers there. First
there are 250000 zeros, then 250000 ones, and so on. The client
reads only the first memory location in a loop, and prints out the
value if that value is not yet printed.
What practically happens is that shmserver has enough time to
increase the values multiple times before shmclient gets its
turn to check the values. shmclient does not print values such
as 1234, 1235, 1236 --- the scheduling period is too long for
that. In fact, the shmclient prints the values surprisingly
slow; maybe 20 times per second at maximum.
Without "renice 19" the shmclient prints values in steps of 24 (avg),
and with "renice 19" the shmclient prints values in steps of 2 (avg).
Maybe 20 times per second with "renice 19". Slow.
What this could mean? When an audio software does non-realtime
background computations, the other non-realtime processes could be
in trouble even if they run at different user priorities.
These processes could be a disk server, a GUI, etc.
Question: does the same "shared memory" problem occur with threads?
Intuitively there should not be problems, but never know after what
I have seen.
Best regards,
Juhana
Hello. Can anyone convert the file
http://www.genisis.ch/casimage/DATA/PlayerPRO_Source_Code.sit
to some better archive format? (zip or tar)
I have also other sit/sea/hqx files which I would like to have in
Linux friendly format. All related to audio/graphics open source
development, of course!
Best regards,
Juhana