Game controllers? - Overtone

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Game controllers?
Received-SPF: pass (google.com: domain of ros...@gmail.com designates 209.85.215.50 as permitted sender) client-ip=209.85.215.50;
Received-SPF: pass (google.com: domain of ros...@gmail.com designates 10.152.133.144 as permitted sender) client-ip=10.152.133.144;
MIME-Version: 1.0
In-Reply-To: <CAGzaFtLKQm+eG9Xk36-duPAjqgsPRpC=3htFqpDQmCWuhnx...@mail.gmail.com>
References: <2351902.10390.1329994796207.JavaMail.geo-discussion-forums@vbbed8>
 <1B7EA6EF497642A4A49322697CA2E...@gmail.com> <CACi_E-T9TcZZ1AfEmTcMMvgNQ9s6vX3uGhYLDNcfLxUR21e...@mail.gmail.com>
 <572976E32D764A10AEF27C1E82799...@gmail.com> <33483190.89.1331031735451.JavaMail.geo-discussion-forums@vbw15>
 <CAGzaFtKTKkdzU+nabAuiLcsXmvf49fq0PE_GvTJOiU5qa+G...@mail.gmail.com>
 <CAFnsTvkKXUSiU+yPY_2Z+pr7kLHyviTL=XK9sZ9x6owBa3a...@mail.gmail.com> <CAGzaFtLKQm+eG9Xk36-duPAjqgsPRpC=3htFqpDQmCWuhnx...@mail.gmail.com>
From: Jeff Rose <ros...@gmail.com>
Date: Tue, 6 Mar 2012 14:55:23 +0000
Message-ID: <CAFnsTv=Y3iXB6GqtJod6QHoCQ+KDU8so0xsGTgmYGyMadqQ...@mail.gmail.com>
Subject: Re: Game controllers?
To: overtone@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yeah, I completely agree with you.  I hacked a simple bit of state
into synths and instruments in order to modify their default parameter
values with GUI controls, but after reflecting on it I think we really
want to have this as a separate piece of functionality.  The
synthesizer should be a simple specification of the directed graph of
ugens, and then on top of it we need machinery to store state and
functions that lookup this state when triggering the synth.  Ideally
we could define groups of state, including named parameters with
documentation, initial values, range, stride (linear, exponential,
etc.), and probably other metadata.  This would then let us map GUI or
physical controls onto the state, and we can have a library of
functions that help to do things like map from linear to logarithmic
within a certain range, or support scrolling subsets of controls like
you describe.

This is on top of the simple event layer though, rather than built
into it, because in many cases it is useful to have a raw interface to
easily hook into without any repercussions.

-Jeff

On Tue, Mar 6, 2012 at 12:57 PM, Tom Oinn <tomo...@gmail.com> wrote:
> On 6 March 2012 12:43, Jeff Rose <ros...@gmail.com> wrote:
>> I think it would be ideal if the low level communication API worked
>> along the lines of the midi interface, where a handler function is
>> called with an event map. =A0Then on top of this, we can build out some
>> more generalized abstractions for components like button grids, sets
>> of sliders / dials, keyboards, velocity sensitive drum pads for
>> percussion, etc. =A0Seem reasonable?
>
> I think the API should be a bit smarter. MIDI has its own issues in
> terms of resolution, but that's by the by and is largely fixed with
> OSC. The more important point is that we want to track the state of
> virtual controls, and both MIDI and OSC are event based protocols. I
> think the API should be trapping these events and using them to both
> call interested parties and update state of a software proxy to the
> hardware and of an intermediate layer between the representation of
> the actual device and the client code.
>
> We need to handle and store state so that if I create e.g. a virtual
> grid of 100x100 buttons which can be toggled, and want to surface that
> onto a grid of 8x8 physical buttons + scroll keys (i.e. a launchpad or
> small monome) there has to be somewhere to maintain the state of the
> controls which aren't currently being made available so that when we
> scroll across we can update the hardware appropriately. Client code
> would bind to events from the 100x100 grid, and a mapping function
> would manage the translation in both directions of events between the
> client, through the virtual console, through the hardware's proxy and
> to and from the actual device.
>
> Given this someone could write code which required, say, a 4x5 button
> grid, three rotary encoders and four faders, and depending on what
> hardware you actually had on hand (degenerate case - mouse and screen
> or keyboard) you could map one or many physical devices into this
> virtual console. Those of us with home studios and lots of space get
> to play with all the hands on controls, someone on a laptop still
> accesses the control functionality through an on-screen or keyboard
> mapped equivalent. It's also nicely modular in terms of effort, once
> we have the virtual console protocols and types the work required to
> add a new hardware device is a distinct package and can be done by
> someone who actually owns one.
>
> Tom
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
