X/Y control in Patcher

#1

X/Y pad. For controlling more than one parameter at a time. Fractional is most wanted :slight_smile:

Module requests
#2

I'm afraid that this won't be possible as those controls are somehow hard-coded or something... I can only select from a limited list. If you want to have xy-control, add a joystick to the axoloti. The two outputs then serve as xy-controls (well, kinda duh.. but stil..)
guess you'll need ask johannes for this one if you want a xy-controller-module in the patcher itself

#3

No worries. I have been looking a bit a the code, trying out different things, but could not find any code that could be called up for the X/Y pad. Could probably be done at object level, writting the X/Y pad in the object itself with out calling anything up from other libraries.

Anyway, no expert on the issue, so I thought I'd swing it by you, the more experienced coder :wink:

About asking Johannes, Jaffasplaffa(anon5189335) have all ready proposed this before.

#4

well, I'm experienced in coding synthesis, not in re-coding the axoloti itself..
the knobs are part of the axoloti core-code, so they cannot be changed by altering that code itself.. which is Johannes' job..

#5

I must say, I don't really understand the utility of an XY pad control within the Axoloti Patcher application.

If you have a MIDI controller with an XY pad, that makes sense as a tactile device, but it just outputs two different MIDI CCs, which you can then map to anything you like in your patch.

At the risk of sounding like a troll, it seems odd to me that lots of people seem to think of the Patcher application as the primary means of playing a patch.

The way I see it, if you're going to to use the screen and a mouse to play your patch (as opposed to just to create the patch in the first place), you may as well not use any external hardware at all. There are lots of more sophisticated software-only modular patching applications on the market, many of which have any number of graphic widgets built in.

Axoloti was envisaged as a standalone instrument, which could be used without a computer, and that's its strength, I think.

If you're always using it plugged into a computer, then the whole thing becomes a bit pointless, really.

Just my personal opinion, of course.

a|x

#6

So far there is a one-to-one relationship between parameters and values. One parameter controls one value. For a XY-pad, one parameter needs to control two values. That breaks with the concept of assigning parameters to midi, modulating them, and presets. I'm aware of other cases where bundling the presentation of two or more parameters is useful, like showing frequency response of a filter, combining cutoff and frequency, or oscillator pitch with coarse/fine adjustments etc, but this requires deep changes in the code.

#7

@toneburst

Look at an X/Y pad as a tool, that can be used in the patcher, for example for controlling more than one parameter with only the mouse. I think this is a pretty valid usecase. You only have one mouse, right?

Well, I have seen Jaffasplaffa saying this exactly the same before. And the answer for him was "oh it is not only for stand alone mode, it is aimed for many purposes"... So, no, it is not really only intended for stand alone use. It has many usecases.

But TBH I dont see the problem in having tools that is mostly usable when only using the patcher. If you dont see any value in it, then dont think about it. There are a lot of things I dont find valuable, I just choose not to use it. But that is my 2 cents.

For example all the integer boxes cannot be assigned to midi, for example ctrl/i. Should that object be thrown away becuase it does fit in all usecases? I dont think so. Likewise with an X/Y pad.

I would find an X/Y pad valuable and I am pretty sure a lot of other would too. Not everyone have loads of hardware to control their Axoloti, not everyone has got the ability to neither write their own objects or build their own hardware. And for people like this, an X/Y pad would be a valuable tool.

No it does absolutely not become pointless. I think this is really vague argument. It shows that you expect that everyone uses Axoloti in the same way you do and that is the only use of it. Ask the developers and I am pretty sure they will tell you Axoloti has got many use cases.

But hey, Always up for a good debate :wink:

#8

I dont think so.

X controls a value, for example midi CC 10

Y controls a value, for example midi CC 11

So, parameters do not control more than one value. It is a combination of 2 parameters that controls 1 value each.

But I am not really so much thinking about specific midi cc object. I am thinking about just an X/Y pad, with a modulation output for X, that sends one value and a modulation output for Y, that controls another value. If you want to assign to midi cc just connect them to midi cc objects that all ready exists.

The usescases you represent are valid but there are many other use cases, one I mentioned in my post to toneburst.

I just think that the idea of 1 parameter controls 2 values is a misunderstanding. That is not how X/Y pad works. If that is your perception of it, you might need to read up on it. It might be a barrier for creating it.

#9

Kaos Pad wiki page:

The Kaoss Pad can also be used as a MIDI controller,
with the x- and y-axis positions of a finger on its pad being output
via a MIDI out connection as two continuous controller streams. The sum
of the x and y positions can also be output as a third continuous
controller stream.

#10

Cool. Will see what goes down. Thank you for the answer anyway )

#11

Sorry, I should have been clearer: one parameter has a single, independent representation in the Axoloti code. XY pads require an entity that contains two parameters. That's not a simple change in code.

You don't need an XY pad in Axoloti to make patches for a Kaosspad.

#12

Cool. Thanks.

I now that and I have no intention for that. It was just an explanation of how X/Y pad works, that the parameters are independent.

#13

@grimmreefer

the UI code is written in Java, which is then exposed to the object editors etc. these then have to also generate code which talks to the firmware (to update parameters etc).
it is open source, so others could contribute to this development if they wish.

the single value parameter, Johannes is mentioning, I think probably refers to the parameter table, which each parameter is stored as 32 bit integer.... that is the current model.
an x/y control would require 2 values, which we dont model currently (regardless of how the stream is then fed to objects), one possible work around I suppose would be 2 16 bit values, squashed into 1, but reducing the resolution is not nice, and then means decoding has to be done carefully and differently to other params.
a better solution would be some kind of 'compound parameter', but thats gets into more dev effort.

EDIT: oops overlap with johannes :slight_smile:

#14

I don't think it's too bad to use 2 16bit parameters if that would allow us to have a xy-controller.. I'ld do it for that..
next to that, isn't it possible to make a 64-bit controller? Then you just shift one of the two controls 16bits and you can add them to each other.

But then again... you can always add a korg nano-pad... or something alike..

#15

But that 'd conflict with MIDI mapping. If there would be a xy-pad you'd want to be able to midi-map it to a real xy-pad too. Such workarounds really complicate future development.

#16

well, I don't really see the importance of an xy-control module that's controlled by an actual xy pad.
my own use would mostly be for testing out new modules and patches without the need of assigning external controls to it or anything..

but you could make it controllable by adding two inputs to the module, scale them down to 16 bit internally and add these together as a 32-bit value to set the xy position of the controller.. then a switch to select whether you want to use it from the computer with a mouse or use the inputs to update the module and show their positions, this would also make it fit as a xy-scope... bam! two flies in one hit!

#17

Please understand my concern, adding it in this way complicates future development.

#18

it's ok with me, if I want xy control, I just connect my korg..or add a joystick to the external input..

#19

You could just connect the output of the X/Y internal pad to midi cc out objects. I dont see why it should be midi cc assignable in itself. Many other objects cant do that either.

#20

NOTE: Ive moved split this topic, since it was 'off-topic' and is a requirement to alter the Patcher UI not a module

+1

I'll just add, that the parameter implementation is already 'up for review' for a future version, there are a few things we want to do with parameters that are currently not possible, and adding 'exceptions' like this, will just complicate re-write/refactoring.
its far better, that this is taken as a 'use-case' for the future implementation, and so incorporated into that design.

(if your interested in some of the reasons for future plans for parameters, there are a number of topics in the developer category. these are not the only reasons, but some of them)