Hi all! Back to real Linux via PC: has anyone used the Roland Octa-Capture in Linux yet? I'm running Ubuntu 12.10. It doesn't show up in /proc/asound/cards, so am assuming it isn't automatically supported. When doing dmesg after connecting, its make, model, and serial number are identified, but it doesn't seem to know what type of device it is. Are there drivers available yet somewhere, assuming that's what I need? A google search a few months ago didn't show anything that looked hopeful. I'm only interested in the audio analog ins and outs, not really controlling it or using digital, as it has front-panel controls. Thanks in advance for any assistance.
Kevin
Hi folks,
Just wondering if anyone has used this controller on linux, and
whether it supported well or not.
It seems like a great tool, small 25 note keyboard, 8 pad drum
controller, 8 asignable knobs.
Thoughts?
thanks
Rusty
On Thu, May 16, 2013 at 8:10 AM, David Robillard <d(a)drobilla.net> wrote:
> On Wed, 2013-05-15 at 13:01 -0700, J. Liles wrote:
> [...]
> >
> > You've seen the consequences of these design decisions in Rui's
> > response. As extensible and awesome as your design may be on paper,
> > the end result is that users get overly fancy, in consistent (and
> > probably slow) GUIs that fiddle with parameters through hidden
> > channels and have poor accessibility. I think that is a real problem.
>
> Meh, the facility is genuinely useful for certain things. Like anything
> it can be abused, but you can't legislate good programming.
>
> As usual the reality was not a choice between plugins doing the right
> thing, or the wrong thing, right now; but a choice between plugins
> existing whatsoever or not. Mailing list bullshit tends to suggest the
> former is reality, but it is not. Reality check: No user would rather
> simply not have e.g. the JUCE plugins whatsoever. Don't like them?
> Don't use them. Nobody loses anything by plugins existing.
>
> As the incentive to do things correctly increases (e.g. hosts doing
> fancy things, or not supporting instance access at all like Ingen), then
> plugins will move to them. If separation is better, then real-world
> incentive will reflect that, and things will evolve appropriately. It
> won't be the first kludge to die in LV2 land, and it won't be the last.
>
> It is a small problem at this point in evolution, but it's not a design
> problem, it is a simple "work that needs doing" problem.
>
> ... or, in the case of host authors, not-work that needs doing. Don't
> like it? Don't implement it. Plugins that want to work in your host
> will then have to adapt.
>
> A custom UI not working is hardly the end of the world anyway.
>
Fair enough except for the last sentence. The point of this thread is that
for some people, it is at least the end of the road. We're talking about
freshly developed, 100% free software plugins can't function without their
custom GUI. This is not about some legacy thing, or some bridge to JUCE.
This is what has come out of the technology, and I don't expect it to stop.
We'll just end up with a situation where half of LV2 plugins only work in
QTractor and Ardour and users don't really understand why other programs
won't/can't support them.
An API *is* by its nature legislation, David. And when your legislation is
full of loopholes what you end up with is usually very different than what
you originally had in mind.
I wish to use a RME BabyFace [1] with Ubuntu. Did someone do it
once? Does a driver exist for such RME product? Someone told me that
it's possible but so far I couldn't find how.
Thank you for your
reply,
Best regards,
Camille
Links:
------
[1]
http://www.rme-audio.de/en_products_babyface.php
Forwarding this to LAU, as no one has responded on linuxsampler-devel.
See message below.
---------- Forwarded message ----------
From: Kaspar Bumke <kaspar.bumke(a)gmail.com>
Date: 8 April 2013 20:44
Subject: sf2 instrument index
To: linuxsampler-devel(a)lists.sourceforge.net
Hi,
I am having some trouble relating the instrument index that LS uses to
the one that FluidSynth (FS) displays.
For instance, for the FluidR3GM.SF2 that comes with FS, FS reads bank
0, program 0 as being "Yamaha Grand Piano" and bank 0, program 127
being "Gunshot". LS reads FluidR3GM.SF2 as having "Gunshot" as
instrument index 0 and 125 being "Yamaha Grand Piano". What logic is
LS using to determine these indexes?
Regards,
Kaspar
---------- Forwarded message ----------
From: Kaspar Bumke <kaspar.bumke(a)gmail.com>
Date: 12 April 2013 17:42
Subject: Re: sf2 instrument index
To: linuxsampler-devel(a)lists.sourceforge.net
Just to make this a bit clearer:
LS reads:
0 - "Gunshot"
125 - "Yamaha Grand Piano"
FS reads
0,0 - "Yamaha Grand Piano"
0,127 - "Gunshot"
On Wed, May 15, 2013 at 11:21 AM, David Robillard <d(a)drobilla.net> wrote:
> On Wed, 2013-05-15 at 10:27 -0700, J. Liles wrote:
> >
> > On Wed, May 15, 2013 at 2:16 AM, Paul Davis
> > <paul(a)linuxaudiosystems.com> wrote:
> >
> > forcing IPC on the GUI is (a) stupidly expensive (b) stupidly
> > complex (c) limits host options.
> >
> > Regarding (A), expensive in terms of what? Pulling the libs for a
> > giant GUI toolkit into my host process is expensive. Expensive in
> > terms of communication? No. A few knobs and sliders and even a scope
> > or eq graph are not going to present any bandwidth problems even on
> > modest hardware.
>
> *Forcing* IPC is stupid, as is not having the *possibility* of IPC.
>
> However this is not an OR, and would only be an issue for a crap design
> anyway. Conceptually, you use a protocol (i.e. POD "events" or
> "messages"), and leave the transport up to the host. Given
> multi-threading and RT this is pretty much how you have to do it anyway.
>
> If the host actually need IPC, then it can use it (e.g. a socket). If
> not, it can simply avoid all the complexity and overhead (e.g. memcpy,
> ringbuffer).
>
> There are many open questions about plugin APIs, but this is not one of
> them. The best solution is obvious, and doesn't require everyone to
> agree on IPC or not. Network protocol stacks have layers for a reason.
>
> Even if the transport was the same everywhere, making plugins
> specifically deal with all that would only result in a bunch of broken
> junk. (Ignoring a few rules), the plugin and UI don't have to worry
> about multi-threading, and talk to the world via synchronous POD. They
> aren't running in the same thread, of course, but that's the host's
> problem. Plugins should have *one* communication mechanism, and in LV2
> that mechanism is ports. Whether an event came directly from another
> plugin's output, or was delivered by carrier pigeon from the GUI running
> on a steam powered control panel in the desert is none of the plugin's
> concern.
>
> -dr
>
>
You've seen the consequences of these design decisions in Rui's response.
As extensible and awesome as your design may be on paper, the end result is
that users get overly fancy, in consistent (and probably slow) GUIs that
fiddle with parameters through hidden channels and have poor accessibility.
I think that is a real problem.
Hello everyone!
I've got one or two questions about LV2 plugins in general.
I've been experimenting with a couple of sound generating plugins, using
mod-host, i.e. not using the plugins' own UIs. Now I noticed, that a couple of
plugins did not show all their necessary controls in LV2 ports.
Examples are the ZynAddSubFX LV2 plugin
http://home.gna.org/zyn/zynadd/1
or the simple sampler by Rui:
http://samplv1.sourceforge.net/lv2
In Zyn there were no LV2-control to control the engine. the sampler offered
a fair deal of controls, but didn't allow me to sample or load a sample. I
could connect an instrument to the input ports and apply the effects (chorus,
flanger, phaser and delay) to it.
So: is there - in theory - an LV2-port type, that allows sending strings -
i.e. filenames. Is there another standardised way for plugins and their UIs to
communicate? If not, are there thoughts about such things in the LV2
developing community for just such cases, where one can't or doesn't want to
use the original UIs of a plugin?
Warm regards
Julien
----------------------------------------
http://juliencoder.de/nama/music.html
