Download from http://www.notam02.no/arkiv/src/
E-Radium V0.61b
---------------
Released 12.7.2005
INTRODUCTION
------------
E-radium is Radium and a special version of E-UAE.
Radium is a midi music editor for the amiga and E-Uae is an amiga
emulator.
This version of E-Uae is a hacked version of 0.28cvs, which runs
with realtime priority to get accurate timing and supports alsa-seq
to access midi. It does not hog the cpu as much as e-uae does
either so it can be used together with various sound synthesis
software running simultaniously in linux.
E-radium has been tested with both the 2.4 kernel and the 2.6 kernel
and with a ~1GhZ machine and a ~2ghz machine. (A 2.4 kernel with a
100hz resolution timer will proably not work very nice though.)
COMPILING
---------
make
RUNNING
-------
1. Run ./e-radium
2. Unpress the "Pause" button.
3. Select which resolution you want to run radium with.
4. Connect midi-ports with qjackctl, aconnect, qconnect or similar
tools.
CONFIGURING THE KEYBOARD
------------------------
If you are a non-us keyboard user, you might have to configure
the keyboard by setting the approporitate type.
e-uae currently supports fr, us, de, dk, se, it and es. Pick the
one closest to what you use, and put it into the "kbd_lang"-field
in the file ".uarc-radium".
(The keyboard should rather have been mapped directly from the
keys though....)
QUICK RADIUM GUIDE
------------------
* Move the editor-window to front, press "Ctrl + 1".
* Maximize the editor-window, press "Altgr + 1"
* Maximize the tracks in the editor-window, press "Ctrl + m"
* Move the playlist-window to front, press "Ctrl + 2".
* Move the Midi-properties-window to front, press "Ctrl + 3".
* Move the Help-window to front, press "Ctrl+4". (Use right mouse
button to access menues)
* Play song press Altgr+Space.
* Play block, press Right windows + Space
* Stop: Press space
* Continue song: Press Right Shift + Space
* Undo: Press Right Windows + U
* Redo: Press Right Windows + Right Shift + U
* Toggle midi-editing on/off, press Esc.
* Move 10 lines up/down: Press Left shift + up/down
* Move between tracks: Press AltGr + left/right
* Add block: Press Ctrl + f
* Move to next block: Press f
* Move to prev block: press a
* PANIC! Hold down left and right mouse buttons for 2-10 seconds.
The player should then stop.
+ A lot more. Check out bin/keybindings.conf for the complete
list. This file can also be editied.
ABOUT MIDI
----------
E-radium creates 8 public alsa-midi seq ports. Currently, only
the 2 first ones are enabled. To enable more, check out the
file s/startup-sequence.
On the linux-side (alsa-seq), the name of the ports are uae0,
uae1, uae2 and so on.
On the amiga-side (camd), the name of the ports are mmp.0,
mmp.1, mmp.2 and so on. These are directly connected if
enabled in s/startup-sequence.
Radium is currently configured to read midi from the uae0 alsa
midi port.
LINUX VERSION OF RADIUM
-----------------------
Radium runs quite okey on its own (v0.63), but its not quite
there yet. Until its there, running it via uae is the only
way to use it besides using a real amiga of course (altough
that is much slower than emulating).
LINKS
-----
Radium: http://www.notam02.no/radium/
E-uae: http://www.rcdrummond.net/uae/
--
Hi,
i have searched the web and the ALSA pages and found very little
information concerning the status of the development efforts, if
any, and who might be interested.
This card seems like a good means to hook a notebook into a DJ
mixer, splitting the output into 2 or 3 stereo outs.
I am very interested in such a driver, but I dud find a reference
to a kernel PCMCIA bug on the ALSA sound card list. How much of a
showstopper is it?
Is there any problem that could be fixed by throwing money at it?
And, if it is a money problem, if the funds were available, how
long would it take for a driver to be completed? My minimum
requirement would be a driver that would support the Audigy 2 ZS
Notebook as well as an Audigy Platimun or SB Live! is supported.
Melanie
Hello all!
I am here to ask you one thing. If I want sample-precise realtime
control for the plugin, should I be getting all the parameters inside
the cycle which travels through the buffer contents?
E.g., should the code that looks like this:
fParameter = *(psMyPlugin->m_pfSomeParameter);
pfInput = psXShaper->m_pfInputBuffer1;
pfOutput = psXShaper->m_pfOutputBuffer1;
for(lSampleIndex = 0; lSampleIndex < SampleCount; lSampleIndex++){
/* do something with the data */
}
be replaced by this:
pfInput = psXShaper->m_pfInputBuffer1;
pfOutput = psXShaper->m_pfOutputBuffer1;
for(lSampleIndex = 0; lSampleIndex < SampleCount; lSampleIndex++){
fParameter = *(psMyPlugin->m_pfSomeParameter);
/* do something with the data */
}
I believe the answer is yes... But maybe I'm wrong?
Thanks!
Artemiy.
Ladies, gents, and those in between,
I got back into the hacking thing a couple days ago, and I'm pleased to
announce new versions of both the Specimen sampler and the Phat Audio
Toolkit. As always, the real tip can be had at www.gazuga.net. The
stuff that I remember changing follows:
Specimen
--------
* Fixed CPU hogging
* Added keyboard for setting MIDI parameters
* Made patch list auto sorting
* Made volume logarithmic
PHAT
----
* Added a new widget, the PhatKeyboard
Stay tuned for more!
Peace out,
-Pete
Hello,
I just did some rereading of some parts of the "What Parts of Linux
Audio Simply Work Great?" thread, that talk about the problems with
soundcards that do not support multiple streams, and thought it would be
good if we could actually come up with an advice to the desktop
developers (Gnome and KDE mainly), distribution developers, and audio
application developers in general.
This document should contain a detailed description of the current
situation, of how we got there (i.e. how the desktop "sound daemons"
actually created bigger problem than a solution, and why alsa does not
do mixing in software by default), of how different user requirements
lead to different solutions that are not always compatible (i.e. the
"professional audio" vs "normal" users), and of all the different
solutions currently available (and interfering with eachother).
I believe such an overview is essential. I think most people on this
mailing list have a pretty good idea about his, but do others? For
example, I get the impression that there is a lot of misunderstanding or
ignorance about alsa and dmix.
Then it should propose an ad-hoc solution, and some guidelines of how to
work towards a future in which everybody (including jwz ;-) ) is happy
with linux audio that "just works". (I found jwz rant unjustified and unpleasant, but we can use it in our advantage if we give the right response, which, with a bit of luck (?) will get the same attention from the slashdot hords as jwz's blog)
The ad-hoc solution, I believe, is something that should work "right
now", or at least, as good as possible, with as little as possible
changes to existing applications. For one, this would mean: making sure
that dmix is being used when necesary, that no applications use the hw:
devices explicitely, but the "default", that OSS applications use
libaoss (If I understand correctly, libaoss can be told the use the dmix
plugin, while alsa oss emulation will always use the hw device, or am I
wrong here?). This is mainly a thing of the distro's.
The remaining problem here is what to do with jackd. When the
"professional" user runs jackd, and jackd complains that it is not using
the hw: device directly, the solution should be obvious for him, and the
non-jack apps should continue to work like before (but should be
restarted, I suppose). Could anyone comment on this? The "occasional"
jackd user can just run jack through the dmix plugin, which, if I
understand correctly, would cause higher latency, but we are not talking
about the "professional" user here.
Proposing a roadmap for the future is much harder, but I think we can
talk about that later.
For now, I would like your opinion on the issue. Do you agree that such
a document would be feasible and useful, and that the proposed
structure/contents make sense? I am not sure that the mailinglist is the
best way to write this document, maybe we could use a Wiki. I guess the
first step would be to look for the relevant messages in the "What Parts
of Linux Audio Simply Work Great?" thread, and write a short overview of
those.
maarten
hello,
any advice on what would be the best kernel options
when using ingo molnar's patch for an audio setup?
CONFIG_PREEMPT_DESKTOP: Preemptible Kernel (Low-Latency Desktop)
or
CONFIG_PREEMPT_RT: Complete Preemption (Real-Time)
CONFIG_PREEMPT_SOFTIRQS: Thread Softirqs
CONFIG_PREEMPT_HARDIRQS: Thread Hardirqs
yes or no?
right now i am building with CONFIG_PREEMPT_DESKTOP,
CONFIG_PREEMPT_SOFTIRQS and CONFIG_PREEMPT_HARDIRQS
maarten
at some point in the past, Thorsten Wilms did write:
> While ladspa control dialogs tend to be ugly, and things like having
> sliders for boolean values sucks, I can't say i miss plugin GUIs like
> I got to know while using Cubase VST much. Inconsistent eye-candy
> nonsense and useless big marketing labels everywhere ...
surely you forgot poor contrast?
keke ;)
Pete.
