Leigh Marble

Does anyone have advice or a workaround for this:

When running plug-ins in Ableton Live, all keystrokes seem to be trapped by Live itself. I cannot get my plug-in to grab any keystrokes. Please try the example patch (to be built into a plug-in) below, it contains both "textedit" and "key" objects.

my systems:
OS 10.3.9 and 10.4.8
Live 3.0.4

text-entry-in-plug-ins-ableton-live-traps-all-keystrokes

For the record, text entry works fine in Pro Tools, so there's not a problem with my patch per se.

Live takes all keys as potential input (to trigger clips), so I'm guessing it just never passes keystrokes on to a plug-in. But if anyone has any knowledge of workarounds, I'm all ears.

Am 21.12.2006 um 09:31 schrieb Leigh Marble:

> Live takes all keys as potential input (to trigger clips), so I'm 

> guessing it just never passes keystrokes on to a plug-in. But if 

> anyone has any knowledge of workarounds, I'm all ears.

I think it was discussed before that its up to the host to decide 

wether your plugin receives keystrokes or not. You could maybe use the 

Am 21.12.2006 um 09:31 schrieb Leigh Marble:
> Live takes all keys as potential input (to trigger clips), so I'm 
> guessing it just never passes keystrokes on to a plug-in. But if 
> anyone has any knowledge of workarounds, I'm all ears.

I think it was discussed before that its up to the host to decide 
wether your plugin receives keystrokes or not. You could maybe use the 
hi object though (haven't tried).

Thank you, trying the hi object is a good idea, I'll let you know...

Unfortunately, the [hi] object doesn't work either.

So, for the record, that's key, hi, and textedit, all rendered inert by Ableton Live.

I believe this is a known issue with Ableton stealing all input in 

I think that Ableton wants to guarantee that keystrokes map to 

controls regardless of the plugins in use.

I'm not sure if any of the plugin specs (VST, AU etc.) make any 

guarantees about non-plug param inputs at all. Notice that the AU 

Validator on os x doesn't test for keyboard or HI input. I am not 

even sure if allowing GUI input is required. My personal lesson here 

is that all of your plugin params should be full-blown plug params. 

This allows for reproducible automation of all params as well.

On Dec 28, 2006, at 12:24 PM, Leigh Marble wrote:

> Unfortunately, the [hi] object doesn't work either.

> So, for the record, that's key, hi, and textedit, all rendered 

I believe this is a known issue with Ableton stealing all input in  
general.

I think that Ableton wants to guarantee that keystrokes map to  
controls regardless of the plugins in use.
I'm not sure if any of the plugin specs (VST, AU etc.) make any  
guarantees about non-plug param inputs at all.  Notice that the AU  
Validator on os x doesn't test for keyboard or HI input.  I am not  
even sure if allowing GUI input is required.  My personal lesson here  
is that all of your plugin params should be full-blown plug params.   
This allows for reproducible automation of all params as well.

>
> Unfortunately, the [hi] object doesn't work either.
>
> So, for the record, that's key, hi, and textedit, all rendered  
> inert by Ableton Live.
>
>


>Unfortunately, the [hi] object doesn't work either.

>So, for the record, that's key, hi, and textedit, all rendered inert 

That doesn't really surprise me. Ableton probably wants to *always*

be able to do their mapping thing for interface control, since it's one

of the "selling points" of the app. I'm sorry.

In general, you'll find this to be true - while any number of applications

will host formats that pluggo supports [AU, VST, RTAS] and while

pluggo is a sort of "wrapper" that lets you design plug-ins that do

interesting things, it is *still* the case that there are decisions that your

host application's programmers may make over which we have no

control whatsoever. I'm sorry that that's so, since it bugs *me*, too.

on the floor there's a long wooden table/on the table there's an open book/

on the page there's a detailed drawing/and on the drawing is the name I took

>Unfortunately, the [hi] object doesn't work either.
>
>So, for the record, that's key, hi, and textedit, all rendered inert 
>by Ableton Live.

That doesn't really surprise me. Ableton probably wants to *always*
be able to do their mapping thing for interface control, since it's one
of the "selling points" of the app. I'm sorry.

In general, you'll find this to be true - while any number of applications
will host formats that pluggo supports [AU, VST, RTAS] and while
pluggo is a sort of "wrapper" that lets you design plug-ins that do
interesting things, it is *still* the case that there are decisions that your
host application's programmers may make over which we have no
control whatsoever. I'm sorry that that's so, since it bugs *me*, too.

gregory
-- 
on the floor there's a long wooden table/on the table there's an open book/
on the page there's a detailed drawing/and on the drawing is the name I took
Gregory Taylor http://www.rtqe.net


you could easily assign ableton key commands to various functions of your plug in , if they are defined as a parameter

Quote: Leigh Marble wrote on Thu, 28 December 2006 21:24

----------------------------------------------------

> So, for the record, that's key, hi, and textedit, all rendered inert by Ableton Live.

Logic does it too. The only way to work around these things is to make your plugins communicate with max via midi or udp and handle the rest in Max.

Quote: Leigh Marble wrote on Thu, 28 December 2006 21:24
----------------------------------------------------
> Unfortunately, the [hi] object doesn't work either.
>
> So, for the record, that's key, hi, and textedit, all rendered inert by Ableton Live.
>
>
----------------------------------------------------

Here's a thread in the JUCE forums that addresses this issue:

http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=1662

text entry in plug-ins - Ableton Live traps all keystrokes?