Trouble with index variable for loop inside loop

[VirtualVirgin]

@d-healey said in Trouble with index variable for loop inside loop:

@VirtualVirgin Might be a HISE bug, change the loop to for (j = 0; j < 127; j++) and it works.

Oh right!
I did come across this before where I couldn't generate that top note (127)!

[ustk]

@VirtualVirgin @d-healey Yeah this bug is here since the premises of Hise, I reckon I pushed a fix one day but it has never been merged

int ScriptingApi::Synth::internalAddNoteOn(int channel, int noteNumber, int velocity, int timeStampSamples, int startOffset)
{
	if (channel > 0 && channel <= 16)
	{
		if (noteNumber >= 0 && noteNumber < 127) // should be noteNumber <= 127
		{

[ustk]

@VirtualVirgin @d-healey Alright I fixed it and made a pull request

[ustk]

Wowww... It appears this error is repeated in many places!

[ustk]

@d-healey shouldn't a MIDI CC start from 0 to 127?

When clicking on a slider to assign CC it goes from 1 to 126...

Something is telling me Chris put a 1 for a reason...

if (!isOnHiseModuleUI && getMacroIndex() == -1)
	{
		auto addNumbersToMenu = [&](PopupMenu& mToUse)
		{
			auto value = handler->getMidiControllerNumber(processor, parameterToUse);

			for (int i = 1; i < 127; i++) // <= 1?
			{
				if (handler->shouldAddControllerToPopup(i))
					mToUse.addItem(i + MidiOffset, handler->getControllerName(i), handler->isMappable(i), i == value);
			}
		};

[d.healey]

@ustk said in Trouble with index variable for loop inside loop:

shouldn't a MIDI CC start from 0 to 127?

Yes

From the MIDI spec

[ustk]

@d-healey Alright I pushed all the changes, hoping I didn't introduced any mistake...

[VirtualVirgin]

@ustk Does that mean I can build from the newest version to get these changes to take effect?

[d.healey]

@VirtualVirgin You'll need to wait for Christoph to check and merge the changes, or you'll need to make a fork and pull in Ustk's changes to your fork.

[VirtualVirgin]

@d-healey said in Trouble with index variable for loop inside loop:

@VirtualVirgin You'll need to wait for Christoph to check and merge the changes, or you'll need to make a fork and pull in Ustk's changes to your fork.

I don't have any forking experience so I'll wait on that, thanks :)

[Christoph Hart]

@ustk pull request looks OK, I guess I never bothered about that upper number too much, the only thing I'm not sure is whether to show CC#0 in the learn popup. Usually you start with CC #1 (the mod wheel) and this will affect all plugins. Does anyone else have an opinion on that?

[d.healey]

@Christoph-Hart CC0 is bank select isn't it? If so I wouldn't show it in MIDI learn.

[ustk]

@Christoph-Hart yeah the cc0 learn was my concern too

[VirtualVirgin]

@Christoph-Hart
I would think it's best just to let the user decide if they want to use it, like any other CC.

Now, upon testing the CC learn (I was curious to make sure it is blocking the consumed CCs at the output for use with MIDI plugins, and it does), but I must say that the CC learn being channel agnostic is not a good idea. This is not how most VST instruments will handle this.

Here in this simple MIDI utility I made, I just ran a test to check the channel filter operation in conjunction with the MIDI learn.

The MIDI learned control to CC#1 (Velocity Transpose Amount) is not affected by the channel filter, so even if my notes aren't going through, my CC values are.

The MIDI learns need to be channel selectable somehow in order to work in multitimbral settings where the VSTi endpoint is only meant to receive from one channel, otherwise you will have lots of unwanted CC messages going to the other channels/instruments.

Is there a way currently to make sure the CC learn can be filtered by channel?

I am not seeing channel selection in the MidiLearnPanel: