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

#14

Hummmm the button idea is not bad at all, it is at least something :smiley:
Still, it would be good to be able to jump wherever you want without having to push the button more than once.
But by now the button thing is going to be what I do.
I wish I could help with the java code but I don´t know the first thing about that :S
I´m pretty sure now that Axolotis are open to buy things like these are going to get fixed fast

#15

Well, I am aiming for automation of everything I do in a patch(using cc to automate whatever). The control objects must be cc assignable... Or else you could might as well just use a constant. To me the point of calling it a control object.... is that you can actually control it?

I know there might be something about midi cc only goes from 0-127. and some parameters goes way beyond that... But that side works in other programs, so it is also possible to program in Axoloti.

Anyway. I am stuck with almost all my patches ATM.... Cause they are all based on ctrl/i objects.. And I cant get further before I figure out how to control it with midi.

#16

you can assign the button to a midi button

#17

ctrl/button is not midi assignable. WHich one you use?

#18

I apologize, i didnt use a button, i used something a bit more complex that i think of as a "button" as it is a trigger from a button on my midi controller. Heres the LFO mod matrix from one of my patches:

Mod Matrix.jpg1072x591 71.6 KB

Erm i was a bit misleading also with the second portion, the second portion determines in this case whether an ADSR, or the LFO's are modulating the cutoff of a filter

This is a part of a virtual analog polysynth patch i made, i can post the full patch if you want, but its very CPU heavy and can only be ran in four voices to my memory. I have a paired down one with only two lfo wave forms and two osc wave forms that can be ran in 6 voice poly as well. There is another mod matrix which selects OSC wave forms, but it is essentially the same concept.

#19

Smart set up :wink:

For just controlling from an external midi device and change simple things like for example selecting 1 of 3 lfos or 1 of 3 filters..... your set up, will work fine.

But I am aiming for using midi cc to control parametes internally in Axoloti(to show visually what is going on in the patch.. Youll see when the parameters move if they are controlled my midi cc) as well as controlling from external device.

Anyway, will see what happens down the road. I have a friend who studies at the University where Miller Puckette is associate director and he is learning to program java as we speak. I hope he might be able to help us out(if developers are looking in other directions than what I am thinking of).

Anyway, Axoloti is still really killer.. Just a small bump in the road. When I started building bigger patches I didnt check which buttons/knobs/etc. were cc controlable. Should have checked it befor I went to deep. Coming from Nord G2 I just assumed all parameters were assignable.

#20

BTW

What does the LP K-filter do after the lfo? dont understand their function yet.

#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)