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...)
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.dkhttp://modlys.dk
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...)
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.dkhttp://modlys.dk
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
>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.
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.
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.
