On Mon, 27 May 2013 19:42:19 +0200
petah wrote:
> Cool, did you use a generic MIDI over TCP encapsulator or something
> like usb2ip?
It was a from-scratch program more like usb2ip.
> Did you have plans to require less attention from the user? I'm
> guessing higher-end gear owners don't have as
short addition, the hardware controllers are 'multi-touch', so that should
be taken to account for an emulator
>
> Hello petah,
>
> i found this a good idea. It would include a new tool that can run virtual
> devices and behave like the original MIDI-wise on operation.
> To define a new device fo
Hello petah,
i found this a good idea. It would include a new tool that can run virtual
devices and behave like the original MIDI-wise on operation.
To define a new device for developers to make work with mixxx, using an
image and the MIDI implementation table, and some graphical x/y mappings
and
On Mon, 27 May 2013 11:26:19 -0600
Neale Pickett wrote:
> For a while, I was working with a guy in Spain (I'm in the United
> States) on a driver for his Hercules Steel. We were both on IRC, he ran
> a userspace program that interfaced with his controller with a TCP
> connection. I was able to ask
For a while, I was working with a guy in Spain (I'm in the United
States) on a driver for his Hercules Steel. We were both on IRC, he ran
a userspace program that interfaced with his controller with a TCP
connection. I was able to ask him to hit buttons or slide controls over
IRC, and the output ca
Hey,
On Mon, 27 May 2013 03:14:50 -0400
RJ Ryan wrote:
> 1) It's valuable to have a structured representation of the mappings. Code
> is a black box and Mixxx has no visibility into it. This means that
> mappings expressed purely in code are not manipulatable by Mixxx. It
> doesn't matter what th
(splitting from 'hate Javascript' thread)
Been wondering of a way to develop drivers offline, i.e. without physical
access to a hardware controller.
Right now only people who have physical access to the controller can write a
driver, so 'owner' == 'coder', which is a huge limitation.
Let's say
HI RJ,
When you say that the XML is good for usabiity, do you mean because you do
not consider editing a XML file as "writing code", or because it is
automatically edited by Mixxx preferences GUI?
In the later case, it could still be used internally, but get rid of it
for scripting purposes, wher
Hi RJ,
I fully agree with your thoughts!
But let me explain my "get rid of XML" idea.
Almost All Midi mappings have an *.xml and a *js file. It is a pain to
maintain them.
The coffee script approach is (correct me if I am wrong) to generate them
both in a single process.
Advantage:
* single loc
On Fri, May 24, 2013 at 4:20 AM, Daniel Schürmann wrote:
> * It is really good idea to get rid of the XML file. There is always a
> confusion for new users how to use it.
>
* I am not in favor of a high end mapping GUI, because the controllers are
> to different to set up a universal GUI solution
Hi everybody,
I'm on a climbing trip but I just wanted to chime in with some comments.
Here are some of my thoughts:
1) It's valuable to have a structured representation of the mappings. Code
is a black box and Mixxx has no visibility into it. This means that
mappings expressed purely in code are
11 matches
Mail list logo
