Linux-audio-user March 2009

linux-audio-user@lists.linuxaudio.org

120 participants
123 discussions

[LAU] Fwd: [Rosegarden-user] [Rosegarden-devel] First-time experience with MIDI playback

by alex stone

On Wed, Mar 25, 2009 at 2:28 PM, Chris Cannam <cannam(a)all-day-breakfast.com>wrote: > On Wed, Mar 25, 2009 at 2:45 AM, D. Michael McIntyre > <rosegarden.trumpeter(a)gmail.com> wrote: > > Discuss. > > No argument about the need to try to improve on the old experience. > > I do think though (as I mentioned the other day in an off-list email) > that any time the user has to go to the Manage MIDI Devices dialog, > the terrorists have already wo-- sorry, I mean, the rest of the > interface has failed. > > That joke was a bit old. I apologise. > > This I think is the use-case in which I think RG 1.x fails most > seriously (because it fails in bad and unpredictable ways, and because > it's a common use-case): > > 1. User starts RG > 2. User starts qsynth, timidity, or some other software synth (this > might happen before 1, but the result is similar) > 3. User wants to play their composition through that synth > > RG 1.x fails this for two separate reasons. First, if it creates a > new device for this synth, the device will have some totally unhelpful > name because RG is too non-committal to give it a sensible name. > Second, even if you were prepared for that, it's just as likely to > connect the synth up to some device that already existed but was not > connected before. > > It should not be necessary to go to the Manage MIDI Devices window to > make this one work. I suspect that a lot of casual users never even > find that window, apart from anything else, before dismissing the > program as impossible to use. > > Removing device auto-creation doesn't really help with that one. The > critical part is being able to select your target synth using a > meaningful name (not just some virtual RG device) directly in the user > interface, preferably directly from the track header. This could mean > either auto-creating a device with the right connection and just > naming it more sensibly, or making it simpler to select the > _connection_ rather than the device (i.e. to redirect an existing > device to a new connection). > > Here's the other big important use-case: > > 1. User uses RG for something, saves file > 2. User loads file later, presses play > 3. User expects file to play through same synth(s) as before > (assuming they are available). > > Removing device auto-creation _does_ help with this one, but it still > won't guarantee we always get it right -- we'd still be at the mercy > of the auto-connection-to-similar-sounding-connection-name logic, > unless we expected the user to always restore their connections by > hand every time they loaded a file. At least, removing device > auto-creation should make it easier to fix this situation if the > defaults come up wrong. > > I was hoping to be able to link to an illustrative video about this, > but I can't find it any more. At last year's Linux audio conference I > had to go up and help out Julius O Smith (noted Stanford DSP guy) > during his presentation because he couldn't get Rosegarden to play to > the synth he was trying to demonstrate (a software synth of his own > devising). The cause of the problem was that, although he'd carefully > saved his composition with the right device connected to the right > connection, a new USB MIDI device had been connected at some moment > between his last successful test and the live demo, and the track was > playing to that instead. Worse, the USB device was a controller > keyboard with no synth (it was playing to the keyboard's MIDI output > port to which nothing was connected). Two people failed to fix this > before I went up. > > Removing device auto-creation would go some way to solving that > problem, but only to the extent that the device came back up connected > to the right connection even though the available ALSA MIDI devices > had changed and re-ordered since the devices were set up. If that > failed, it would be much more apparent how to fix it if the connection > was more obvious and more easily editable in the main GUI itself. > > Just for completeness, there is also a third use-case which was > prominent in our minds when we first (mis-)designed this stuff: > > 1. User makes composition > 2. User passes composition to friend > 3. Friend lacks same MIDI devices, but device names in composition > help friend work out how to recreate the setup > > > Chris > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Rosegarden-user mailing list > Rosegarden-user(a)lists.sourceforge.net - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-user > possible option 4? First opening of the midi device manager shows GM device, and an extra entry, titled "Add new connection". It does precisely that, and the user selects from a dropdown list of connectable devices, that RG has detected. And as each connection is added, the "Add new connection" option stays in view and ready to rumble, at the bottom of the list. Another vote here for user creatable jackmidi ports. (For future consideration.) Alex. -- Parchment Studios (It started as a joke...) -- Parchment Studios (It started as a joke...)

16 years, 11 months

[LAU] firewire soundcard, recommendations please

by Atte André Jensen

Hi I'm looking for my first firewire soundcard. I need: * min 4 outs * min 4 ins * at least one of the ins should provide 48V * at least 2 (3-4 would be better) ins should be non-48V mic ins Looking at http://www.ffado.org/?q=devicesupport/list, and the price tags, this brings me down to the following three: Echo AudioFire 4 Edirol FA-66 Focusrite Saffire LE Now I'm looking for recommendations. I assume they all work flawlessly with linux, right? How about sound quality (convertes, preamps), latency and stabillity? Are there any cards I've overlooked, esp something that'll provide 3-4 mic preamps? Thanks in advance for any input. -- Atte http://atte.dk http://modlys.dk

16 years, 11 months

[LAU] hpet timer

by alex stone

Might be a bit of a curly question this one. Currently, most of my templates for LS and RG are setup with alsamidi. I've started converting the LS ones to jackmidi, and i'm starting to use it more and more. My question is: With alsa 1.0.19, i have hpet timing. (and i don't know enough about this, to know if it's been there for a version or two.) Nearly all my linux experience has been with the RTC timer, for better or worse, and frankly, i have little idea which is better, save the conversations we've had here from time to time. So, what does Jack use? I understand alsa sits in my kernel, and communicates with my hardware. Given that, it's using hpet as the timer, and i assume here, that means it's timing midi for me as well. There's also some sort of rtc emulation in this version (from the little info i've been able to glean.) Is there a benefit, timing and stability wise, in using jackmidi for as much as possible, with the a2jmidid bridge to capture older apps using alsa, given the rapid development we've seen over the past 12 months in many corners of our little niche community. Is it time to consider this, as a serious alternative to alsa midi, and what sorts of pros and cons do we face? I'm using a lot of ports, and driven fairly serious chunks of midi data, for my orchestral nonsense, so this is quite important looking ahead. (imho) Some insight into this would be appreciated. Alex. -- Parchment Studios (It started as a joke...)

16 years, 11 months

[LAU] why shouldn't clients autoconnect to jack

by Atte André Jensen

Hi I often heard that it's considered bad when clients automatically auto connect it's outputs to jack. I agree, mostly since: 1) This makes routing through other software before output difficult 2) The patchbay in qjackctl makes it easy to make auto connects anyways But could anyone point me to some explanation from the devs (Paul Davis for instance) of why this is considered bad? -- Atte http://atte.dk http://modlys.dk

16 years, 11 months

[LAU] ardour website

by alex stone

Is anyone else having a challenge connecting to the Ardour website? Alex. Parchment Studios (It started as a joke...)

16 years, 11 months

[LAU] Loading LASH projects from the command promt

by Nikolay Dvoeglazov

Hello everyone, First time poster here, a great community you have here! I'm trying to make an fully automated processor using jack-rack and LASH. The system works fine for the most part, using jack-rack to create the required effect-chain and using lash_control to save and restore the project. Problem is, I couldn't find any way to use the command-line parameter to load the lash project. Is it even possible? I want to use this machine as a headless FX-processor and boot the FX-chain automatically. Any suggestions are most welcome! Thank you, Nickie

16 years, 11 months

Re: [LAU] why shouldn't clients autoconnect to jack

by sonofzev＠iinet.net.au

>Whatever autoconnect scheme jack could provide, it >would not please some app authors. They would want >to be sure to be connected to playback-1 and -2 >while jack might connect them to -7 and -8, and >that would actually make more sense than wanting >to autoconnect in the first place. So they would >just bypass jack's --no-autoconnect option by doing >it themselves. > >You can't stop people from behaving in uncivilised >ways or being rude by law, nor by being polite >yourself. In the same way you can't stop apps from >autoconnecting by trying to make it impossible, or >by providing an alternative. The problem is not >technical, it is the attitude of application authors >thinking they can decide in the user's place. > >From a user perspective, autconnecting apps never seems to match the user requirement. The more complex the studio, (usually when there is a physical patch bay involved) the more complex the connection scheme maybe, or it maybe changing constantly through a piece of work.. So within Ardour, I turn off Autoconnect(thankyou for allowing me to do this), and with other apps I have to go in and undo the connections they initiate on startup... I really need to get my head around Lash... then maybe my life will be easier.

16 years, 11 months

Re: [LAU] why shouldn't clients autoconnect to jack

by Kjetil S. Matheussen

nescivi: > On Monday 23 March 2009 14:58:38 Kjetil S. Matheussen wrote: > > Without that, the other things I said would have been incredibly stupid. > > > > > i do agree that it would be good to define some "system aliases" so that > > > it was possible to reliably and controllably discover *which* physical > > > ports to connect to if autoconnect is going to be used. > > > > That sounds too complicated. Why not just add a command line option for > > jackd for selecting which client to autoconnect to? > > I don't think JACK should be complicated by defining autoconnect > mechanisms in > there. > > Applications should provide the option and configuration for it. > I think the proposals given for the app to ask upon first startup (either > via > a GUI if the app has a graphical interface, or through command line > interface > if not) to the user how you want to configure the behaviour is the > clearest > way. > > The configuration dialog can suggest the first hardware ports by default, > if > that is the expected most common user case. > > That way the user is aware that he can configure it, and can adapt the > program > to her needs. Letting jack autoconnect doesn't prevent applications from setting up a custom connection system, so the above suggestion is beside my point, and it doesn't address the problems I was addressing either. The problem with jack is that application writers simply don't bother to do all the work required to handle configurable connection handling, and instead they just autoconnect to the physical outputs. If jack had autoconnected by default, we wouldn't have had this problem.

16 years, 11 months

Re: [LAU] why shouldn't clients autoconnect to jack

by Kjetil S. Matheussen

Atte Andr? Jensen: > > Hi > > I often heard that it's considered bad when clients automatically auto > connect it's outputs to jack. I agree, mostly since: > > 1) This makes routing through other software before output difficult > 2) The patchbay in qjackctl makes it easy to make auto connects anyways > > But could anyone point me to some explanation from the devs (Paul Davis > for instance) of why this is considered bad? > This is a design fault in jack. Jack should by default always autoconnect new ports to physical in/outs when they are created. (first created port is connected to the first physical port, and so on) In addition, a jackd command line option to turn autoconnect off is required for those who (for good reasons) don't want that behaviour, or those who want to autonnect to a different client than the client handling the physical in/outs. And there should also be an option which turns autoconnect off for specific ports (i.e. an extra argument for jack_create_port). I think this would have pleased everyone.

16 years, 11 months

[LAU] Web-based Notation

by David Baron

Folk seeking notation alternatives my check this out! http://www.noteflight.com

16 years, 11 months

← Newer
1
2
3
4
5
6
7
8
9
...
13
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-user March 2009