• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: Controller mapping
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Controller mapping


  • Subject: RE: Controller mapping
  • From: john smith <email@hidden>
  • Date: Tue, 11 May 2010 08:02:28 +0200
  • Importance: Normal

Hi,
 
thanks for your reply.

> Logic manages the hardware controller centrally, which makes way more
> sense to me than having each individual plugin attempt to manage the
> controller separately.
 
Exactly! This is what I would expect.
 
> Have you even considered how your plugin
> could possibly instruct the host where to place parameters when it
> has no idea what positions are available?
 
Yes, I would expect the plug-in to have maps for each type of controller layout it wants to support. This is what is done in ProTools.
 
> You could create a GUI in your plugin for mapping
> to one of these, but would you try to support every option from
> Mackie?
 
In this particular case, we would actually only support 1 specific controller. But in other situations I might want to support the "main" controllers, yes.
 
> What about hardware controllers from other companies like
> Behringer and Euphonix? Logic also supports hardware controllers
> from companies like TASCAM, which is why I prefer to have the host
> handle as much as possible.
 
There's nothing stopping you from having both.
 
What I mean is... When a controller is attached, the host checks the plug-in to see if it has a map for this particular layout. If it doesn't, well, then it can simply proceed using your preferred method.
If it has, all the better, it can switch to that layout.

> I do not understand your complete dismissal of MIDI.
 
Well, the communication is 1-way, as Bill says, so already there we don't want it.
 
There's other reasons, but I fear that getting into those will remove focus from our task, and might start a discussion, which is off topic.
 
> The fact is
> that these hardware controllers send MIDI messages to the host, so
> you can't really expect support for anything fancier than what the
> controllers themselves are using. The interface between the primary
> Mackie MCU Pro and the extension modules is quite literally a MIDI
> cable.
 
Yes, but what I was talking about was Bills suggestion that we listen to MIDI messages. *That* is not good enough.
 
> The extenders are nothing more than simple MIDI controllers
> with a particular protocol. It sounds like what you're asking for is
> a new hardware controller standard in the industry, rather than
> compatibility with what is currently on the market.
 
Not at all.

On the contrary.
 
 
All I'm asking for is a way to improve positioning on existing controllers.
And actually, besides positioning, also a way to give the controller short versions of the display names and parameter strings, but I was saving that for when my first problem was solved (if it gets solved).
 
 
Again, I hope I'm clearer now, and that these misunderstandings can stop :-)
 
 
Thanks,
 
Michael Olsen
PhonoXone
 


Hotmail: Trusted email with powerful SPAM protection. Sign up now.
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >dynamic parameter lists (From: Paul Davis <email@hidden>)
 >Re: dynamic parameter lists (From: Stephen Blinkhorn <email@hidden>)
 >Controller mapping (From: john smith <email@hidden>)
 >Re: Controller mapping (From: Brian Willoughby <email@hidden>)
 >RE: Controller mapping (From: john smith <email@hidden>)
 >Re: Controller mapping (From: William Stewart <email@hidden>)
 >Re: Controller mapping (From: john smith <email@hidden>)
 >Re: Controller mapping (From: William Stewart <email@hidden>)
 >RE: Controller mapping (From: john smith <email@hidden>)
 >Re: Controller mapping (From: Brian Willoughby <email@hidden>)

  • Prev by Date: Re: Controller mapping
  • Next by Date: Re: Question about the AudioConverterFillComplexBuffer callback function
  • Previous by thread: Re: Controller mapping
  • Next by thread: Re: dynamic parameter lists
  • Index(es):
    • Date
    • Thread