What defines if a button/knob is capable of being controlled by midi CC?

#21

i used it to smooth out the edges of the lfo wave form a little bit, as i found the effect of the lfo in saw, triangle and square(where it has sharp edges) to cause the osc to produce an unpleasant audio artifact. No idea if this still happens, it may now be an unnecessary component

#22

I fixed the midi mapping for the "ctrl/i radio *" objects, new release coming soon...

"ctrl/i" is still not mappable, since its range does not make sense to be mapped to MIDI.

Custom minimum and maximum values for controls need deep thought on the user interface. I'd like to avoid object properties dialogs as much as possible. My intention is that one should be able to reconstruct a patch from a screenshot. This is already not the case with midi mapping, presets, and modulations - at least the "C","P" and "M" indicates that a parameter has extended settings, but that is only the case with dials, sliders and (radio) buttons do not have this indications.

#23

Thank you for the update, @johannes :smile:

Will get it and test it :smile:

Did you just edit in the XML editor or is this done in java? I would really like to know where to look, so I can try and make a 0-127 version of the ctrl/i that reacts on midi CC. That shouldnt be too hard as long as the range is within midis range(128), right? And it would solve a lot of issues in my setup.

Any input is welcome :wink: (You can PM me if you like instead of here).

EDIT: just checked on Github. Couldnt find it there... New release is always welcome :wink:

#24

This is done in java.

Why not use "midi/in/cc i"? Ok that does not allow tweaking the value from a patch, or monitoring the value. Monitoring can be added with a disp/i object.

How to use modulation sources
#25

Yeah I just checked it doesnt monitor the value.

I also use a lot of the disp/i object. But the problem is I have used the ctrl/i in almost all my patches and a lot of them. So I would have to change all patches I have made. To me it makes more sense to reprogram the ctrl/i for a new version than changing all patches. I will have to create it eventually cause I prefer that object over the dials, etc. and also cause they take a lot less space and I like to look at numbers instead of th dial :smile: And it is also different looking at the actual number move that a display...

But I dont really understand what is going on in the java code. It looks way different than the XML code. I dont see anything referring to 0-127..

PS. Where do I locate that file in Axoloti content on Mac?
Edit1: Found it!
Edit2: No didnt find it anyway. Thought I did but the mac search engine lcated an older version i compiled from Git. I cant find the file in latest release

#26

There is a semantic difference between integer and fractional. Integer = counts, (almost) unlimited range, green wires. Fractional = fraction of a certain maximum value, blue and red wires. MIDI mixes these semantics all the time...
If you need the 0-127 range you're probably dealing with the fractional interpretation, and I recommend to use ctrl/dial.

This modification raises concerns here, I doubt I'd integrate this.

Sorry I'm not in a position to teach java...

This is java source code, and not part of a release.

#27

Thank you for the answers. It comes clear to me that what I am trying can create other problems.

If I understand this correct:
If I find out what to edit in java to add midi to ctrl/i it will also affect other objects or functions of Axoloti?

I kind of thought it would be as easy as changing the min/max value of the ctrl/i. That was pretty easy. But this seems like a bigger task.

#28

The problem is not implementing, but the semantics and future compatibility.
If you change it you can make patches that no one else can open.

ctrl/i is "rangeless", it can be adjusted to values that you then cannot reproduce via midi.

#29

Cool, so it is possible without messing up "the rest of" Axoloti :smile:

I dont really worry about that. If they like to use it, they could just do the same? What I really like about Axoloti is that it is customizable in almost any possible way. And i Like to take advantage of that :smile: And thanks for that btw :wink:

Ive made a bunch og custom ctrl/i objects like 0-15, 1-16. 1-64, etc..... And adjust value to what I need, cause I prefer that you can not drive the ctrl/i beyond the maximum value needed. For example if you use the ctrl/i to select position of a sequencer with 64 steps. Then you dont want the ctrl/i to go beyond 64 steps, cause everything beyond is not used. There are many situations were this could be applied to(And that is also one of the reasons I also mentioned that a "dynamic version" of the ctrl/i would be nice, where you can set minimum and maximum value, maybe from axolotis own editor or something like that).

A little more explaining about this: This version doesnt have to go to rangeless. It just needs to stay within 128 steps... 0-127 .. with in midi range, That is perfect. and if you change the minimum value to 60, the midi cc value would probably still be 60. I am pretty sure if the ctrl/i CC object(i call it for reference) is set to send out 0-127 value it will still send out the correct values by defalut, even though you change minimum and maximum value. Like for example set minimum to 30 and max to 60 then it would probably also send out those midi values. But that is not so impotant, you can always adjust the output with math to give the values you need. The most important part is that it is midi cc assignable, so you can see the exact values when edited from external device or modulated from internal mod source.

That is stays within 0-127(probably easier to make cc compatible)
setting minimum and maximum can be done externally so I dont worry about that. DOesnt have to done inside, but would off course be welcome.

Another example of why I think the ctrl/i is a better choice than the dial.
Accurate display of value:
I am using a homemade step lfo made from sel/sel i to trigger some drumloops.. Basically for slicing them. And to choose which exact step of the step lfo that is selected I use the ctrl/i. If you use a ctrl/dial you would have to guess from what position the dial exactly has. You can not see the exact value, like with the ctrl/i where you see it visually. For example 64 steps covers 16th notes over a range of 4 bars. If I want the loop to start from step 16(2. bar of the loop) and not 1(1.bar of the loop) it is way easier to set the value with ctrl/i in a live situation than doing it with a ctrl/dial. You can always see the exact value.

I also use the ctrl/i instead of the radio obejct.. cause the radio object are very big. /again here the "dynamic" version would be very nice.. still within 0-127).

Come to think of it.. A ctrl/dial, but with a different visual than a dial could do just fine. Maybe it is easier to make a version of the dial with a diffrent interface that shows values instead of a knob? THen it willl stay with in 0-127 no matter what :smile:

#30

ex.png828x168 13.9 KB

#31

Messing with the semantics and future compatibility is messing up "the rest of"....!

You could fork it and publish your incompatible version.
But will you keep doing efforts to maintain and support your version?

Adding 100rds of variations of ctrl/i objects for different ranges is not a good solution in the long run, I'm not going to maintain these.

I do understand your needs, and I think they will be addressed in the future, but this is a substantial change that needs a lot of care.

#32

Sorry. I didnt know that was what you ment :wink:

well, if it was just only a few lines of code, it is easy to copy paste into a new installed versions as they come. Anyway, will se what happens, I dont want to mess the installation up. For now I'll dig a little deeper in axoloti and see what other solution there could be :smile:

I dont expect you to. I make new versions for different needs. Again that is what I like about Axoloti; it is customisable in many ways. Most need are for now covered with custom ctrl/i version, like 1-4, 1-8, 1-16, 1-32. 1-64, 1-128... So it it is not really that many or that complicated. But it just makes the patch more clean. If the ctrl/i is in a subpatch and controlling for example a muxer with 8 inputs and it has unlimited values.... It will easy drive beyond the muxers 8 inputs... with the 1-8 the ctrl/i just stops when it gets to 8. So you can only select the values that actually controls something :smile:

#33

new module:
sss/ctrl/intMidi

enter midiCC(0-127), channel(1-16) and max value (2-127) in the text field like:
33,6,87

(this case would be (cc 33, channel 6 and max 87)

The module "intMlist" returns values given in a list below the cc,channel and max settings, like:

33,6,5,
0,
56,
44,
75,
24
(it's easier to put the value below each other for easy readout of how many entries you have->
linenumber minus 1)