New builds

[atom]

Well i talked with JULES on the forums and it looks like it’s a windows specific problem. On linux (i’m testing this right now at work) it works fine. Windows i blocking the programs messages queue for some reason, now i’d need to either put a artificial delay between calls when loading a panel or find a way to wake the queue up after the panel has been loaded.

The dumbest thing i could think of that could work would be to re-create all async components (combos, lists, buttons) after load (new components work fine).

I really don’t know how to deal with this.

[dasfaker]

I’ve been following your chat, he talks about old windows versions… how old? On Windows 7 it doesn’t work, not so old OS.

atom wrote:

The dumbest thing i could think of that could work would be to re-create all async components (combos, lists, buttons) after load (new components work fine).

The big problem with this approach is that all my methods call modulators by their index (much faster than calling by name with this amount of modulators), so I need them to be created in the same order they have now (placed with the same order in the xml document). Anyway, if the problem is the amount of modulators, once I would have recreated all of them, wouldn’t the problem arise again?

Thanks anyway for your effort.

EDIT: Another thing I just remembered, on previous Ctrlr revision it works fine, so I would discard the OS issue. Could it be some change in the new revision?

• This reply was modified 9 years, 9 months ago by dasfaker.

[atom]

I think the issue is in the amount of modulators created in a short amount of time (on panel loading). Once that finishes, each of the combos is sort of “dead” but if you create new ones they will work, so re-creating all modulators in some way would work, but this is stupid since it will double the time of loading the panel (that is already very long).

I need to figure something out…

[atom]

I uploaded a new nightly that should be considered HIGHLY EXPERIMENTAL, there are 2 big changes that might cause bad things to happen.

Apart from the 2 changes that i will remove if the fail to work a small fix for the windows message queue bug is there too. It’s a dirty nasty hack but it might do the job. Please give it a try.

[dasfaker]

Wow, it’s working, but…

I’m getting strange issues with several modulators, they can’t be called by name.

I attach a example panel with a modulator copied from my panel. If you try in the console for example
panel:getModulatorByName("P1 OSC1 Text"):getComponent():setPropertyString ("uiLabelText", "Hello")
you get ERROR: attempt to index a nil value

You can call this modulator by index and get it’s name without errors, but once you call it by name it fails. I really don’t understand what’s going on.

There’s something that maybe it’s not important, but modulators like uiLabel and uiImage created with the new builds (not just this last one) have less variables in modulator section than those created long ago with older builds. In the example panel attached you can see that the uiLabel has variables like vstIndex, expressions… Could this mess things?

• This reply was modified 9 years, 9 months ago by dasfaker.

Attachments:

You must be logged in to view attached files.

[atom]

No missing variables are not an issue, they’ll be there because older Ctrlr versions used them. I’ll see about the missing names, like i wrote in the changelog the new getModulator() and getModulatorByName() implementation might be broken for now, if i can get it to work quickly i’ll leave it, if not i’ll just fall back to the previous one.

[atom]

That was an easy and quick fix, labels are static modulators so they are created a bit differently, but it should work now.

Will post nightlies later today with the fix.

[dasfaker]

Ok, thanks.

atom wrote:

No missing variables are not an issue, they’ll be there because older Ctrlr versions used them

Can they be safely deleted then (editing the xml)?

[atom]

Yeah if they’re RED it means that they have been removed from any known Ctrlr definitions (the ID manager does not know what to do with them, so it just ignores them).

[dasfaker]

But the ones I wrote about aren’t red.

New static modulators lack the following variables, present on my static mods:

“Expression to evaluate… 1”
“Expression to evaluate… 2”
“Modulator attached to global variable”
“Modulator does not output any midi during startup”
“Don’t send this modulator during snapshots”
“Link to MODULATOR modulation type”
“Link to what type of property”
“Base/fallback value”
“Called when the modulator value changes”
“VST Index”

Can those be deleted even if they aren’t red? To generalize, can I just compare the variables of my mods with the variables of new mods and delete what is no longer present?

BTW, I miss the Utility tab, very handy to look for the name of a variable.

[atom]

I’ll see why i removed the utility tab…i’m sure there was a good reason for it.

Any yes you can remove any property, in case it’s needed it will get re-created with a default value.

—update
hold on i didn’t remove the Utility tab it’s still there and the XML preview of the selection is still working (i can see that i added some XML text colorization)

• This reply was modified 9 years, 9 months ago by atom.

[dasfaker]

HS, if I select a mod and then press Utility tab it’s empty. I have to deselect the mod and select the mod again to see the code. I’ve never tried this until now, shame on me.

atom wrote:

Any yes you can remove any property, in case it’s needed it will get re-created with a default value.

Cool, thanks.

[atom]

Ah yes, this was a quick fix too, the utility tab didn’t refresh on visibility change.

[dasfaker]

Fantastic work, Atom. All problems seems to be gone.

I only get the same assertion failure in widgets/juce_ComboBox.cpp:105 as before, only one at the beginning of the log file, but everything seems to be working fine. No one message about old panel scheme, neither about indexes out of bounds.

About the experimental hashmap to speed calls with getModulatorByName, it’s still present? If the answer is yes, it is as fast as calling mods by index?

[atom]

Yeah it’s still there, it won’t be as fast but it will be much faster then the previous method. Getting modulators by index will be the fastest way always.

[dasfaker]

I’ll have to test it. Some people is asking for a panel with 16 parts, that would be almost 12000 mods.

I have the feeling that the panel now loads much faster, about 30%.

[atom]

I tried some optimizations so it might be a little faster.
The biggest performance issue right now is loading the XML panel, it’s a lot of string parsing and this is most of the time Ctrlr spends when loading a panel. This is mostly my bad design in the first place, for now i can’t do anything about it, but i will try to optimize what i can in other areas.

[dasfaker]

I’m getting an error here:

GLOBAL_PatchName = function(modulator, newValue)
	b = modulator
	c = modulator:getComponent()
end

attempt to call method 'getComponent' (a nil value)

• This reply was modified 9 years, 9 months ago by dasfaker.

[atom]

When in doubt, do what(modulator) and see what object is getting passed to the function, if it’s not a modulator object then you would get this error, but if that should be there it’s something i’d need to look at but i need more details.

[dasfaker]

Ahh, my bad, I was using this method in “called when the label content changes”, and the function should be myMethod = function(label, newContent).

What is label in this case, the modulator?

[Author]

Posts