New builds

[atom]

No it’s the component (the label itself), again what(label) should tell you what object that is and what methods it has available (in this case this should be CtrlrComponent)

[dasfaker]

It says Object type [CtrlrLabel]. I can’t find any way to know which modulator owns this component. Tried with getParentComponent but I get Object type [CtrlrPanelCanvasLayer]

[atom]

It should be done with the getOwner() method but i see i missed that when declaring CtrlrComponent, i added this now, will be fixed in the afternoon.

[dasfaker]

It’s working now, but maybe there is a bug or I’m missing something.

I have this code:

GLOBAL_PatchName = function(label, labelText)
b = label:getOwner()
console(b:getLuaName()) -- correct, it gives me the name of the mod "P1 GLOBAL PatchName"
if b:getLuaName() == "P1 GLOBAL PatchName"
...
else console("fail") end

I never get the modulator. If I use vstIndex instead of LuaName it works fine.

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

[atom]

You never get the modulator ? but b:getLuaName() works so you must have the modulator object.

[dasfaker]

I get the modulator and get it’s name with b:getLuaName() on the console, but later in if b:getLuaName() == “P1 GLOBAL PatchName” (the name I get on the console) I don’t get the mod.

If I replace the same code with b:getVstIndex(), I get the mod in the “if then” construction.

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

[atom]

I think this might be a Lua issue in it’s core you are comparing a object of type String() and a string, getLuaName() is an alias to getName() and they both return a String()

so in order to compare the actual String() content you should do something like

m = panel:getModulatorByName ("very fucked up modulator")
console (m:getName())
if L(m:getName()) == "very fucked up modulator" then
console ("Yup i got that modulator i needed")
else
console ("Nope couldn't get it")
end

That is put the modulator:getName() in a L() function, this changes the String() object to a std::string object that is known to Lua as an object that has a string inside it.

[dasfaker]

I get it, thx.

[dasfaker]

I’m having again issues with the panel. I get several error messages in the log.

JUCE Assertion failure in components/juce_Desktop.cpp:45
JUCE Assertion failure in memory/juce_LeakedObjectDetector.h:95
JUCE Assertion failure in widgets/juce_ComboBox.cpp:105

It doesn’t happens always. When I get those errors, all mods (sometimes half of them) get value 0, no matter what value they had when I saved the panel.

[atom]

Always, just sometimes ? What panel i need to reconstruct the situation to see what’s going one those messages just tell me there is something wrong with the UI.

[dasfaker]

You can try the panel in the pm I sent you, with this panel I get
JUCE Assertion failure in files/juce_File.cpp:95 The other messages appear in an updated version of that panel. In this updated version I do the following, if you need it I’ll send to you:

1. I have the panel opened and save it.
2. I reopen the panel and it looks fine. No errors in the log. Save the panel
3. I reopen the panel and sometimes all (almost always), sometimes all but a few mods have value 0. Once I reset mods values, go to point 1 and the loop starts again.
The assertion failures messages are intermittent, sometimes appear and sometimes not.
I don’t see anything wrong in the UI, just that all modulators on panel load have value 0 and not the value they had when saved.

[atom]

yeah please send me the updated version for comaprison.

[atom]

So far i couldn’t track your issues, but i found 1 extra in your Lua code, see attachment.

The assertion for the File() class has been removed (it was harmless), i’m trying to reproduce the ComboBox assertion now.

Attachments:

You must be logged in to view attached files.

[dasfaker]

Yeah, that’s how I found the problem. This error appears because some mods have 32 as min value and it’s lua method will fail if a lower value is received, and as I see in the pic, all mods have value 0, so we have the same symptoms. Try saving and reopening the panel, the other assertions should appear.

[atom]

“save the panel” you mean, save the state or re-save the panel as a “.panel” file ?

[atom]

Maybe you could demonstrate a small panel with a piece of lua code that would fail the same way, i can’t catch this assertion.

[dasfaker]

Re-save the .panel file.

Isolating the issue is hard, I don’t know what’s causing it. The same panel for only 1 part doesn’t have problems, so I assume it’s something related to the amount of modulators.

[atom]

The amount can affect timers only, loading modulators might cause timers to trigger extremely delayed or too early.

[atom]

Ok let’s try a different approach, can you tell me what lua method/line modifies (adds) stuff to any combo boxes ? Like adds new elements or, resets the combo contents.

[dasfaker]

You can take a look at methods under Browser folder, global_bank_select and global_open_bank, I think the only combos change their content are two for bank select and two for program select. These combos get reseted on method “Called before a panel is saved” with value -1 (to show “no selection”).

[Author]

Posts