[t0f4st]

done

https://github.com/RomanKubiak/ctrlr/issues/36

[t0f4st]

msepsis wrote:

Im really glad you got it working. Also great to compare notes and get some confirmation from someone else with a similar experience. I hope you didnt try each one since 1590 until you got what you were expecting out of it!!

well in fact i tested every version xD

and i’m only talking about the panel i recreated to showcase the bug. my full panel uses more lua api and i dont want to test all scripts and roll back to work with build 1590!

run the Ctrlr-Win32.exe of any build higher than 1590 and the following code will fail/malfunction:

testString = "Efx1_High"
compareString = "Efx1"
result = tostring(String(testString):startsWith( compareString ))
console (string.format( "%s startsWith %s == %s", testString, compareString, result ))

output:
Efx1_High startsWith Efx1 == false

please fix that

• This reply was modified 7 years, 7 months ago by t0f4st.

[t0f4st]

msepsis wrote:

Try it in 5.3.50.. does the issue persist? If so go back earlier
1590 is my go-to for sanity checking things like this as it was quite solid although missing a few of the updates (Lua, Juce, etc) that the more recent revs have.
Generally in the larger picture of functionality and stability 1590 likely isn’t missing anything you need to be honest, although I have no clue what it is your panel is to be doing.

i have tested the panel in every version. it runs only in the build 1590!!! every win32.exe above this build is malfunction the string method startsWith(…) !!!

[t0f4st]

msepsis wrote:

Common misconception you might share:
“Latest is greatest”
Not true here.

I would recommend going back a few versions in ctrlr.
Incidentally you haven’t mentioned what ctrlr rev you are using – that’s paramount to the types of issues you describe. .

i’m running build Ctrlr-5.3.201.exe
problem exists in build 5.4.2, too.

msepsis wrote:

Try it in 5.3.50.. does the issue persist? If so go back earlier
1590 is my go-to for sanity checking things like this as it was quite solid although missing a few of the updates (Lua, Juce, etc) that the more recent revs have.
Generally in the larger picture of functionality and stability 1590 likely isn’t missing anything you need to be honest, although I have no clue what it is your panel is to be doing.

my panel is doing simple string comparison. it iterates through all modulators in the panel and checks if the modulator name starts with an “Efx#”.

currentModName = mod:getPropertyString("name")
if (currentModName:startsWith("Efx1") == true) then ...

The string comparing is working in x64.exe but not in win32.exe!

i did a simpler readable version of my function to understand the process…

function SingleEfxEnable(efxId)

	console (string.format("SingleEfxEnable (enabledEfxId=%d)",efxId))

	n = panel:getNumModulators() -1

	for i=0,n do
		mod = panel:getModulatorByIndex(i)
		if(mod ~= nil) then
		
			currentModName = mod:getPropertyString("name")
			isEfxModulator = false
			
			if (currentModName:startsWith("Efx1") == true) then
				isEfxModulator = true
				currentEfxId = 1
			elseif (currentModName:startsWith("Efx2") == true) then
				isEfxModulator = true
				currentEfxId = 2
			elseif (currentModName:startsWith("Efx3") == true) then
				isEfxModulator = true
				currentEfxId = 3
			else
				isEfxModulator = false
			end
		
			if (isEfxModulator == true) then
			
				if (efxId == currentEfxId) then
					isEfxEnable = true
				else
					isEfxEnable = false
				end
			
				if (isEfxEnable == true) then
					-- enable Mod and MIDI Message
					mod : getComponent() : setProperty ("componentDisabled", 0, false)
					currentMidiMessage = mod:getMidiMessage(0)
					currentMidiMessage:setPropertyString("midiMessageType", "6")
				else
					-- disable Mod and MIDI Message
					mod : getComponent() : setProperty ("componentDisabled", 1, false)
					currentMidiMessage = mod:getMidiMessage(0)
					currentMidiMessage:setPropertyString("midiMessageType", "9")
				end
			end
		
		end

	end

end

msepsis wrote:

Also incredibly important at least in my experience when debugging stuff like this and testing out different ctrlr revs –
CRITICAL that you trash ctrlr preferences to ensure you’re starting w/o snowballing issues. This is especially important when changing revs.

how to trash the ctrlr prefs?
do you think of deleting %appdata%\Ctrlr\Ctrlr.settings ?
… i already did that.

• This reply was modified 7 years, 7 months ago by t0f4st.

Attachments:

You must be logged in to view attached files.

[t0f4st]

i created a new panel in x64 version to trace back the bug.

open in Ctrlr-x64.exe -> no problem
open in Ctrlr-Win32.exe -> malfunction

Attachments:

You must be logged in to view attached files.

[t0f4st]

goodweather wrote:

Maybe that, as a workaround, you can read the vstindex and value of each modulator and set them one by one with the simple setValue?

yeah, i already though about that manual looping and parsing but it is very slow!

atom wrote:

is the code above a patch you would like to add to Ctrlr ? can you explaing what’s going on there ?

will you implement it in the next built?

[t0f4st]

atom wrote:

That issue is a bit problematic due to Threading issues, the only work around for now is to use setModulatorValue(value, false, false, false) (only the 2nd false/true works anyway and indicates MIDI event), but this might also not work always (the call is not syncrhonus and might sometimes miss the dont-send-midi flag). This is something i know about but have no idea how to fix for now.

does this statement still complie to the current version (5…)??

setValueMapped(const int newValue, const bool force, const bool mute)
setValueNonMapped(const int newValue, const bool force, const bool mute)
setValue(const int newValue, const bool force, const bool mute)
setModulatorValue(const int newValue, bool unused_vst, bool midi, bool unused_ui)

• This reply was modified 7 years, 8 months ago by t0f4st.

[t0f4st]

atom wrote:

is the code above a patch you would like to add to Ctrlr ? can you explaing what’s going on there ?

current usecase:

you have a panel with some modulators. during panel designing you delete and add some new modulators. this will lead to vstIndex’s which aren’t continously (0,1,2,3,4,5,6) rath discontinuity (0,1,2,5,6,100,102,..).

with this panel design scenario in mind data = panel:getModulatorValuesAsData("vstIndex", CtrlrPanel.EncodeNormal, 1, false) will not result valid data !!!

problem is the current getModulatorValuesAsData implementation! the method is expecting and requiring that the propertyToIndexBy is continously!

with the following getModulatorValuesAsData implementation the method call data = panel:getModulatorValuesAsData("vstIndex", CtrlrPanel.EncodeNormal, 1, false) will result in valid data, althought it has alot of unused space – which i dont mind.

first it gets the maximum vstIndex of all modulators used in panel.
with that info it creates an memoryblock with the size equal to the maximum vstIndex.

then the loop starts to iterate through all modulators in panel.
read the moduatorValues and store it in the memoryblock at the position defined by the vstIndex of the modulator.

t0f4st wrote:

i think with this implementation it will be possible to add/remove modulators and the data is still be usable. *i dont care about the unused memory

LMemoryBlock CtrlrPanel::getModulatorValuesAsData(const String &propertyToSortBy, const CtrlrByteEncoding byteEncoding, const int bytesPerValue, const bool useMappedValues)
{

	int minIndex = 999999;
	int maxIndex = 0;

	for (int i=0; i<getNumModulators(); i++)
	{
		const int index = getModulatorByIndex(i)->getProperty(propertyToSortBy);

		if (index >= 0)
		{
			if (index > maxIndex)
				maxIndex = index;
			if (index < minIndex)
				minIndex = index;
		}
	}

	MemoryBlock modulatorData (maxIndex * bytesPerValue, true);
	uint32 modulatorValue;

	for (int i=0; i<getNumModulators(); i++)
	{
		const int index = getModulatorByIndex(i)->getProperty(propertyToSortBy);

		if (index >= 0)
		{
			if (useMappedValues)
				modulatorValue = getModulatorByIndex(i)->getValueMapped();
			else
				modulatorValue = getModulatorByIndex(i)->getValueNonMapped();

			modulatorData.setBitRange (index * (bytesPerValue * 8), bytesPerValue * 8, modulatorValue);
		}
	}

	return (modulatorData);
}

• This reply was modified 7 years, 8 months ago by t0f4st.
• This reply was modified 7 years, 8 months ago by t0f4st.

[t0f4st]

i think with this implementation it will be possible to add/remove modulators and the data is still be usable. *i dont care about the unused memory 🙂

LMemoryBlock CtrlrPanel::getModulatorValuesAsData(const String &propertyToSortBy, const CtrlrByteEncoding byteEncoding, const int bytesPerValue, const bool useMappedValues)
{

	int minIndex = 999999;
	int maxIndex = 0;

	for (int i=0; i<getNumModulators(); i++)
	{
		const int index = getModulatorByIndex(i)->getProperty(propertyToSortBy);

		if (index >= 0)
		{
			if (index > maxIndex)
				maxIndex = index;
			if (index < minIndex)
				minIndex = index;
		}
	}

	MemoryBlock modulatorData (maxIndex * bytesPerValue, true);
	uint32 modulatorValue;

	for (int i=0; i<getNumModulators(); i++)
	{
		const int index = getModulatorByIndex(i)->getProperty(propertyToSortBy);

		if (index >= 0)
		{
			if (useMappedValues)
				modulatorValue = getModulatorByIndex(i)->getValueMapped();
			else
				modulatorValue = getModulatorByIndex(i)->getValueNonMapped();

			modulatorData.setBitRange (index * (bytesPerValue * 8), bytesPerValue * 8, modulatorValue);
		}
	}

	return (modulatorData);
}

• This reply was modified 7 years, 8 months ago by t0f4st.
• This reply was modified 7 years, 8 months ago by t0f4st.

[t0f4st]

goodweather wrote:

What do you want to achieve?

i am serializing all modulatorValues and save it in a file. so i can load that file and all modulator values back to the saving state, and of course sending these modulatorValues also to the midi controller.

there are atleast two ways of archiving this. first: manually looping through all mods and append it to custom structure, that can be parsed….

but then i found the second and propably better way – because its already implemented

serialize with: getModulatorValuesAsData
parse with setModulatorValuesFromData

goodweather wrote:

Why using the VST indexes? What are the advantages/inconvenients in comparison to basic modulator get/set values?

with using those panel methods i need a parameter “propertyToIndexBy”… here comes the vstIndex and its “correlate” problems….

the main advantage of “vstIndex” is that the property vstIndex is already available and i dont have to apply a custom property on each modulator (which isnt that hard to apply but unstable to update)!

if i change some modulators add/delete the saved data should still be usable.

• This reply was modified 7 years, 8 months ago by t0f4st.
• This reply was modified 7 years, 8 months ago by t0f4st.

[t0f4st]

next problem i have is with setModulatorValuesFromData

i can load the modulatorValues with

panel:setModulatorValuesFromData(fileData, "serializeIndex", CtrlrPanel.EncodeNormal, 0, 1, false)

but the modulator with enabled MidiMessage wont send the loaded/updated values!!!

please add a flag to panel:setModulatorValuesFromData

panel:setModulatorValuesFromData(fileData, "serializeIndex", CtrlrPanel.EncodeNormal, 0, 1, false, true)

with the flag enabled modulators with midiMessage will use the loaded Value and sent the midi message.

thanks

[t0f4st]

not quit sure but a non-optimal workarround will be reinit vstIndex, or add an property as customIndex…

reinit vstIndex:

--
-- Called when a modulator value changes
-- @mod   http://ctrlr.org/api/class_ctrlr_modulator.html
-- @value    new numeric value of the modulator
--
reInitVSTIndex = function(--[[ CtrlrModulator --]] mod, --[[ number --]] value, --[[ number --]] source)

	n = panel:getNumModulators()
	for i=0,n-1 do
		mod = panel:getModulatorByIndex(i)
		mod:setPropertyInt("vstIndex",i)
		console(string.format("mod:getProperty('vstIndex') == %d",mod:getPropertyInt("vstIndex")))
	end

end

add an property as customIndex (serializeIndex)

--
-- Called when a modulator value changes
-- @mod   http://ctrlr.org/api/class_ctrlr_modulator.html
-- @value    new numeric value of the modulator
--
InitSerializeIndex = function(--[[ CtrlrModulator --]] mod, --[[ number --]] value, --[[ number --]] source)

	n = panel:getNumModulators()
	for i=0,n-1 do
		mod = panel:getModulatorByIndex(i)
		mod:setPropertyInt("serializeIndex",i)
		console(string.format("mod:getProperty('serializeIndex') == %d",mod:getPropertyInt("serializeIndex")))
	end

end

• This reply was modified 7 years, 8 months ago by t0f4st.

[t0f4st]

if found a possible workarround

currentMidiMessage = mod:getMidiMessage(0)
currentMidiMessage:setPropertyString("midiMessageType","9")

[Author]

Posts