Help me build a keyboard macro.
Comments
-
Probably not the answer, all I can think of is the control rate is super slow. I think 25 hz is the lowest it goes. That way faster than 2 hz. I guess it's worth a try to change the control rate just to see if it fixes the problem Other than that you might check the code and use the debugging tools.
0 -
Thanks, Studiowaves! I got that part working.
What i need to solve now is that a Merge module doesn't simply pass on any signal that arrives at one of its inputs. I thought merging the events wouldn't be a problem, as LMB clicks never happen simultaneously.
I started with building a test for just the one key, and that worked perfectly, so i was already celebrating that this would work out. All i had to do is add all the other keys. So i added a second key.
And it doesn't work. 😂
The Merge module in front of the oscillator Pitch input has a Note Pitch In module and two connections that send note numbers from the "keys". The Note Pitch in and the lower input (49, high key) of the Merge module work perfectly. But when the lower "key" (48) is clicked, the note number is not passed on to the oscillator. Both key connections send a note number into the Merge module when a key is clicked, but the 48 is not passed on to the oscillator and the output remains 0. Not so with key 49.
For anyone who wants to check this out, here's the build you see in the image:
I think, basically what i need is a way for the note numbers generated by LMB clicks to arrive at a single input of the Merge module. I think this might be achievable by use of loads and loads of Compare/Equal modules to divide the Mouse Area module into regions that overlay each key, put it all in a Macro that spits out note numbers according to X/Y coordinates of the LMB clicks on the Mouse Area module.
Greets,
Bolle
0 -
This works. Compare/Equal modules are used to set the X boundaries of the two test keys. This is only a test across the X dimension of the Mouse Area, so two Compare/Equal modules per key to define the left and right boundary of each key.
Two additional Compare/Equal modules will be used to define the Y boundaries of each region, if i want to divide one large Mouse Area module instead of using small ones for each key separately.
Testing continues.
EDIT: This works, of course, for any Mono synth. Not the 8 voice synth i'm trying to apply this to. Lots of phasing and 8 voices firing at once when i change the voice count to 8. Simplest solution i can think of is very crude indeed: to duplicate the entire oscillator section and dedicate one to Midi keyboard play and one to Mouse Button play. Mix them together and Bob's your uncle. I know. 😱
Greets,
Bolle
0 -
Rather than multiple compare/equal constructs with all the mess of merging etc., can't you just use a bit of simple arithmetic?
so lets say it super simple and the 'keys' are all lined up and fill the mouse area completely (reality will be eventually more complex, with black keys etc., but still doable)
e.g.
w is the width of the mouse area
n is the number of keys,
mx is mouse x coordinate
and pl is the lowest pitch.
Then:
key_width = w/n
key_pressed = mx/key_width
and note_pitch is pl + key_pressed
Usually this sort of thing needs some massaging, and will obviously get more complex for offset black keys, but I would definitely go this way rather than a horrible per-key hard wired approach.
You can add offsets to account for rounding...
maybe easier to use core because then rounding to integers is nice and simple. And explicit!
1 -
Normally, yes. This would totally work and be a lot less labour intensive. But the drawback of a 3D GUI is that the width of the area a key needs varies, due to the keys fanning out (i.e. not being perfectly straight) from left to right because of the perspective view. Using Compare/Equal modules, i can adjust the dimensions of every key accordingly.
My main problem, however, is that the Midi Note In module doesn't play nice, being merged with the incoming note numbers from the Mouse Area module. I get multiple voices firing at once when clicking a key.
Other than making a dedicated duplicate of the oscillator section, just for mouse area events, i don't see a solution right now.
Greets,
Bolle
0 -
Yeah, merge can be tricky, I assume if two events arrive simultaneously the bottom input is sent out. Core merge is like that. I think you would like core code for this kind of stuff. These high level modules don't always synchronize like events do in core. I could be the reason for the merge not working.
0 -
I tried a little core cell with a Merge in it. Same same.
Greets,
Bolle
0 -
But the drawback of a 3D GUI is that the width of the area a key needs varies, due to the keys fanning out (i.e. not being perfectly straight) from left to right because of the perspective view.
Personally I don't like that view anyway - as soon as there are multiple modules, the illusion breaks, so I prefer infinite focal length with no fanning as a better overall compromise. However, if you do want the fanning, then it should be possible to calculate that and incorporate it into the calculation.
The midi note thing is more a case of understanding better what is going on and controlling it all. Maybe easier in core. If it's mono, that's not so bad just keeping track of the active key... for poly more tricky, but still achievable. It is probably not a trivial implementations using a merge though!
This kind of thing tends to have subtle corner cases that you need to understand and catch
0 -
Realised I made this edit with the beta, so here's a pic rather than the ens:
1 -
Many thanks, Colin! Trying this out as we speak.
Greets,
Bolle
0 -
I did some fiddling around. It's more or less the method ColB suggested.
There's a couple of misfires here and there. Triggering is flawless but, though key regions and assigned notes are precise and correct, the right note doesn't always come out. It works better with click->drag control than clicking keys individually. I'm sure there's a Separator module needed somewhere or other.
Try it out if you like:
Greets,
Bolle
0 -
Note numbers in the previous upload weren't correct. Now they are, but i still get misfires around the 7th key of every octave. There, it doesn't like to jump from one note to the next. It takes a couple of clicks.
Every octave is a duplicate of the first one, with different values. But i don't see anything wrong with the setup around those keys.
The top part of key 44 fires the completely wrong note, but everything looks to be correct for that section.
Anyone willing to have a look?
Everything works perfectly within the first octave. I divided the the keyboard into separate macros per octave. What i'll try is duplicate the first octave AGAIN, enter the right data, and see if that solves the problem.
All in all this looks promising, though. If i can get this to work flawlessly, imo it'll be the best keyboard build on the U/L. Because it works regardless of the voice count and can be copy/pasted into any instrument.
If anyone is interested in how i determine the placement and dimensions of each region of the keyboard, this is how:
EDIT: i got it working flawlessly all across the keyboard.
Greets,
Bolle
0 -
So far, as I understand this, your using the mouse pointer to press a key. Something I liked in Kontakt was the ability to click on the back of the key for low velocities and closer to the front for high velocities.
How are you reading the mouse location? Does each click return a number like x/y co-ordinance. Break it down for me, I'm suspecting the co-ordinance or mouse location is returning the wrong note. What I would do is use the xy coordinances to index a look up table in the read only memory module. It makes it easy to call the correct note with X location and the possible key velocity with the Y. It's easy to do and doesn't require a bunch of comparators. Example , assume x goes from 0 to 99 for one key, then 100 to 199 on the next. So the lookup table would have the same note value for every index between 0 and 99 and the next note up in memory indexes between 100 and 199. No comparators are needed because the data has been pre compiled in the lookup table.
I put a core cell lookup table that reads the midi volume of 0 to 127 and outputs the DB cut. Not sure what I did, it might have a non linear volume curve, might not. Just to show how a simple table works. I'm sure it'll come in handy for something. Lookup tables are straightforward.
0 -
No velocity sensitivity for LMB control. Only for midi keyboard control. It's too much work and unnecessary.
No wrong notes (any more).
Yes. If zone 1a is X from 0 to 30, i compare those to greater than 0 and smaller than 30. Same for the Y coordinates. Multiply by note number, and out to the oscillator.
Greets,
Bolle.
0 -
Played keys will appear blue. Like so:
But if you modify this keyboard for your project, you can of course use any image you want.
Greets,
Bolle
0
Categories
- All Categories
- 18 Welcome
- 950 Hangout
- 56 NI News
- 471 Tech Talks
- 2.5K Native Access
- 11.1K Komplete
- 1.3K Komplete General
- 3K Komplete Kontrol
- 3.9K Kontakt
- 844 Reaktor
- 299 Battery 4
- 612 Guitar Rig & FX
- 325 Massive X & Synths
- 762 Other Software & Hardware
- 4.1K Maschine
- 4.8K Traktor
- 4.8K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators