Hello list!
I've been looking around at MIDI trackers, and found this:
http://vektor.ca/audio/ttrk/
Also this, apparently based off of the previous:
http://sourceforge.net/projects/bttrk/
I really dig the approach of a console-based MIDI-only tracker.
Unfortunately, these apps want to use /dev/midiXX, and I have no
/dev/midi devices on my system. (I'm assuming this is some OSS
thing.) How can I make this work with my system?
(FYI, I did try Shaketracker, which promptly crashed my system, so
I'll pass on that for now.)
Thanks everyone,
Josh
--
Josh Lawrence
http://www.hardbop200.com
>
> On Tuesday 04 August 2009 02:19:33 you wrote:
>
>>> On Sun, 2009-08-02 at 16:45 +0300, David Baron wrote:
>>>
>>>> What might be a jack-enabled equivalent of:
>>>>
>>>> /usr/bin/ogg123 -d alsa<1> (<1> is and ogg file, obviously)
>>>>
>>>> Preferrable would be something that will play through jack if the daemon
>>>> be running, alsa not (mplayer can work this way but this is a bit heavy
>>>> for a short file play, i.e., a signal from a program).
>>>>
>>> mplayer fits the bill perfectly imho and I'm not convinced that it's
>>> that heavy - it actually uses very little memory when just playing a
>>> sound file (mp3, ogg, wave).
>>>
>> Does mplayer auto sense if jack is being used and fall back to
>> pulse/gstreamer/esd/alsa/oss if not? Maybe David just needs a small
>> script that willl check the existance of a running jack and trigger the
>> correct commandline.
>>
> Done in mplayer with option -ao jack,alsa (pulse can be in this list as well)!
>
That's very handy to know.
>> Does anyone have an example of a bash command to check if jack is running?
>>
>> ex. (untested)
>>
>> !# /bin/bash
>>
>> if(jack_connect 2>&1 | grep "server not running")
>>
>> alsaplayer -i text file.ogg
>>
>> else
>>
>> alsaplayer -i text -o jack file.ogg
>>
>>
>>> If you want a program to have "signal sounds" an external sound player
>>> is bulky regardless of the player used. Jack itself also sounds a bit
>>> overkill. This sounds like the use-case for system sounds, esd, pulse,
>>> etc.
>>>
>> I agree. Do you want this feature to work so that you can hear the phone
>> calls when jack is running or do you have a more specific need for
>> piping the audio through jack?
>>
> I am using the computer, possibly for listening or audio using jack or not.
> The applet needs to work regardless.
>
I have a hunch that this will become a very common scenario so I might
whip up a quick toot for this problem as an example for future
reference... Would you be interested in added a section on your experience?
Just a few lines or a paragraph about what you needed to do and the
solution would be very useful.
>> IIUC the latest version of pulse will use jack if it is running and
>> reconfigure itself to use alsa directly when it is not running. This is
>> the point of the dbus code.
>>
>> However I'm not 100% certain that Kjetils suggested method is the
>> correct way to achieve this. I was under the impression that the latest
>> version didn't need to be configured at all. The dbus code in jack2
>> would take care of the call to reconfigure the i/o sinks. I think
>> Kjetils suggestion means that jack has to be always on before pa is
>> started.
>>
> It would seem that configuration needs jack running to pulse will fail to
> start.
>
What might be a jack-enabled equivalent of:
/usr/bin/ogg123 -d alsa <1> (<1> is and ogg file, obviously)
Preferrable would be something that will play through jack if the daemon be
running, alsa not (mplayer can work this way but this is a bit heavy for a
short file play, i.e., a signal from a program).
>
> What might be a jack-enabled equivalent of:
>
> /usr/bin/ogg123 -d alsa<1> (<1> is and ogg file, obviously)
>
> Preferrable would be something that will play through jack if the daemon be
> running, alsa not (mplayer can work this way but this is a bit heavy for a
> short file play, i.e., a signal from a program).
I do not have a sndfile-jackplay on Debian repos. I just installed alsaplayer
packages. It seems one must choose which plugin to play as well as specify the
sample rate. To reconfigure the calling program when I turn jack on and off is
surely silly at best.
Mplayer's approach of try this one, no ... try the next is what I need without
the fat of mplayer. Since the caller is a kde applet, maybe phonon has the
answer? I do not want to be stuck with knotify (which at best disables or is
disabled by jack).
David Baron:
>
> What might be a jack-enabled equivalent of:
>
> /usr/bin/ogg123 -d alsa <1> (<1> is and ogg file, obviously)
>
> Preferrable would be something that will play through jack if the daemon be
> running, alsa not (mplayer can work this way but this is a bit heavy for a
> short file play, i.e., a signal from a program).
>
>
With pulseaudio, you can simply use ogg123, and you
don't have to give any special options for ogg123,
just write "ogg123 <1>" and you'll get sound through
jack.
Pulseaudio has amazingly well-working jack audio drivers
and alsa interfaces, so finally linux audio works
without hassle for all programs all the time.
This is the only modification I had to do to make it work:
$ grep jack /etc/pulse/*
/etc/pulse/default.pa:load-module module-jack-source
/etc/pulse/default.pa:load-module module-jack-sink
I don't know how pulseaudio is set up on other distributions,
but on fedora 11 everything seems to work very well.
On fedora 10, on the other hand, pulseaudio sometime started
its own jack daemon called "jackdbus" which hogged
the soundcard but didn't produce any sound, but that's
not the case with fedora 11.
>> Agreed.
>>
>> If you want a Debian-based system, Ubuntu is much more focused on
>> requirements for a general-purpose desktop. Not specifically for
>> musicians of course, but easier to adapt for that purpose.
>
>maybe it is more of a trade-off -
This is the big If?.. Why specifically a Debian based distro?
Are you looking for the best performing music workstation, a politically correct
distro, a server or a general purpose desktop?
If the answer is music workstation, why does the choice need to be limited to
Debian?
Many would argue (including myself).. that a ground up type of distro, like
Gentoo, Paludis or Arch are the best way to start. Although Debian if carefully
installed will fit into this category.
I have also found this personally in experience too. I've tried the pre-built
distros for music Studio64, Apodio and UbuntuStudio and GP desktops Mandriva and
Ubuntu and found they were
a) bloated
b) did not contain everything I needed or had old versions of what I needed
c) trying to add things not in the repos was more than trivial
d) did not perform as fast as as a ground up distro...
e) a nightmare come upgrade if any customisations have been made..
Comparatively, I have a number of purpose built Gentoo systems (1 server, 2 media
pc's and one studio computer) and while they take an initial amount of work to
built, once built they are very reliable, and perform amazingly quickly... Should
an app not be available through portage or an overlay .. it is trivial to install
from source.. My audio machine is now back on a standard (gentoo-sources) kernel,
I have done very little in PAM and get fantastic latency results.
Reports from friends using Arch reflect a similar situation.
However, for those looking for an easier option.. AV Linux looks like an amazing
option.. although it is more of an image that needs modification rather than a
distribution per-se. And yes it is debian based...
But to re-iterate my question.. why necessarily a debian based solution, why not
simply look for something that will give you a reliable, fast performing music
machine? Debian may be able to provide this, but why limit the initial question
to something debian based?
cheers
Allan
Hi!
In accordance with http://alsa.opensrc.org/index.php/Dmix "For ALSA 1.0.9rc2
and higher you don't need to setup dmix. Dmix is enabled as default for
soundcards which don't support hw mixing". Ok, I starts 'aplay file.wav' at
two consoles. The second one says:
aplay: main:608: audio open error: Device or resource busy
I have tried asoundrc examples from that page without any success. Alsa
1.0.20, hdsp/RME9632 are in use under Kubuntu Karmic. Other aplay info is:
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: DSP [Hammerfall DSP], device 0: RME Hammerfall HDSP 9632 [RME
Hammerfall HDSP 9632]
Subdevices: 0/1
Subdevice #0: subdevice #0
$ aplay -L
default:CARD=DSP
Hammerfall DSP, RME Hammerfall HDSP 9632
Default Audio Device
null
Discard all samples (playback) or generate zero samples (capture)
This 'null' is rather strange... What have I missed? Where to dig in?
Andrew
Hi folks.
I'm cooperating with a friend and fellow to improve his project
related to wiimote.
The project is Wiican[1]. In short, it is a tool (a system tray icon
actually) that makes it easier to connect the wiimote and configure
and create key mappings for use at your will. It's written in python
and uses bluez, hal with dbus, wminput and cwiid.
My goal is to add some layer in such a way that you can map wiimote
events to MIDI. And maybe, to include it on the next improved release
of Musix.
So, in adittion to my researches on the subject and what I already
know about MIDI CCs and so, I would like some advice and guidance
about how to:
- implement MIDI in python (which CCs are a must for you, create and
send MIDI messages, libs, bindings, reference projects),
- implement Jack and Alsa MIDI ports in python (libs, bindings,
reference projects),
... and every other interesting information or experiences on this.
Thanks in advance.
[1] https://launchpad.net/wiican
--
Carlos "Sanchiavedraz"
* Musix GNU+Linux
http://www.musix.es
I find that I must renice most any media player to at least -5 to get well-
behaved play. I believe the problem is competition with X for resources (I am
running a Debian Sid box with KDE4). Then, my and renicer daemon will set them
back to 0 after I have been listening for a while.
Has anyone here had, solved this problem?
Know how to make exceptions in and configuration?
Would it work to run the players through jack rather than alsa and thereby get
"real time".