Hi, I’m sorry for my ignorance: I can’t move the listbox at my wished position
I’ve tried with setBounds,setMinimumContentWidth but anything happens
Could you help me?
thanx
well setBounds will definitely move it, no question about that! You’re probably just moving it back in your resized() method or something.
Hi,
I used a SimpleListBox to show some file name retrieved from a Open Dialog Box.
But now I need to drag these filename to a target, so I have to use ListBox.
I don’t understand how to fill its rows with my Component, which will be dragged somewhere.
Have I to call n-times the createRowComponent ?
Another question: must I inherit from ListBox to implement this kind of ListBox, and write createRowComponent / updateRowComponent ?
thanx for help
Is there any class to create and manipulate matrices of objects with JUCE?
Something like OwnedArray
This is a programming question.
I reach an heap error executing this code in the Editor constructor:
//Allocation
target = new IRCellTarget* [ins];
//Indexing all coloums
for ( i = 0; i < ins; i++)
target[i] = new IRCellTarget[outs];
for (i = 0; i < ins; i++)
{
for(j = 0; j < outs; j++)
{
target[j][i].setRowCol(j,i);
target[j][i].setBounds(FIRST_CELL_X + i * (cellWidth + 5),FIRST_CELL_Y + j * (cellHeight + 5),cellWidth,cellHeight);
addAndMakeVisible (&target[j][i]);
}
}
The error appears only when the matrix dimension is NxM,not when N=M.
I’m sure you can solve this problem
Thanx in advance
I’m not sure, but why this
target[j][i].setRowCol(j,i);
target[j][i].setBounds(FIRST_CELL_X + i * (cellWidth + 5),FIRST_CELL_Y + j * (cellHeight + 5),cellWidth,cellHeight);
addAndMakeVisible (&target[j][i]);
and why not this, it’s more “logical” (i and j are inverted)
target[i][j].setRowCol(j,i);
target[i][j].setBounds(FIRST_CELL_X + i * (cellWidth + 5),FIRST_CELL_Y + j * (cellHeight + 5),cellWidth,cellHeight);
addAndMakeVisible (&target[i][j]);
I don’t know sylf, maybe yesterday night I slept not enough.
I’m afraid of matrix heap allocation! 
Thanx a lot
String irInfo;
irInfo = T("IR properties: \n");
irInfo += T("samples: ");
irInfo += String ( retrievedInfo.getSFINFO().frames) + T("\n");
fileInfo->setText( irInfo );The output in the Label fileInfo is:
IR properties: samples: 4096
fileInfo is declared in this way:
// IR info label
Font f(10.0f,Font::italic);
fileInfo = new Label(fileInfoName,T("IR properties:"));
fileInfo->setBounds (InfoBoxX, InfoBoxY, InfoBoxWIDTH, InfoBoxHEIGHT);
fileInfo->setFont(f);
fileInfo->setJustificationType ( Justification::topLeft );
addAndMakeVisible (fileInfo);
I’ve tried also with the append() method but I got the same output.
It’s definitely not a string problem, so it must be the label not drawing it right. Which is odd - I just did a multi-line label myself this morning, and it’s fine.
Is your label tall enough to fit two lines of text in it?
oh - that has just made me notice a bug in GlyphArrangement, though…
in juce_GlyphArrangement.cpp, line 735 should look like this:
[code] float dy = -t;
if (layout.testFlags (Justification::verticallyCentred))
dy += (height - (b - t)) * 0.5f;
else if (layout.testFlags (Justification::bottom))
dy += height - (b - t);
[/code]
Yes the Label I think is tall enough (100px).
My Glyph… at this line looks like this (addFittedText):
733: if (length <= 12 && ! txt.containsAnyOf (T(" -\t\r\n")))
734: maximumLines = 1;
735:
736: maximumLines = jmin (maximumLines, length);
737: while (numLines < maximumLines)
{
++numLines;
const float newFontHeight = height / (float)numLines;
if (newFontHeight < 8.0f)
break;
if (newFontHeight < font.getHeight())
{
font.setHeight (newFontHeight);
numGlyphs = startIndex;
addLineOfText (font, txt, x, y);
lineWidth = glyphs[numGlyphs - 1].getRight() - glyphs[startIndex].getLeft();
}
if (numLines > (int)(lineWidth / width))
break;
}Instead a similar code is in the previous method (addJustifiedText).
I’m using JUCE 1.10.
…yes, I’m seeing 1.14 one and there the piece of code…
oh, if you’re still on 1.10, then that’s probably why it’s not working. I think I updated some of the text rendering to handle newlines fairly recently.
I’m upgrading to 1.15.
I builded your JuceAudioPlugin and tested over my host (AudioMulch).
It works fine but when I close the edit view an EZeroDivide external exception occurs.
The same over energyXT.
PS: building the DLL in release mode I have 4 warnings
C:\juce15\projects\MultiVolver\src\wrapper\formats\VST\JuceVstWrapper.cpp(150) : warning C4541: ‘dynamic_cast’ used on polymorphic type ‘class juce::Component’ with /GR-; unpredictable behavior may result
Linking…
Creating library Release/multivolver.lib and object Release/multivolver.exp
LINK : warning LNK4089: all references to “ADVAPI32.dll” discarded by /OPT:REF
LINK : warning LNK4089: all references to “OPENGL32.dll” discarded by /OPT:REF
LINK : warning LNK4089: all references to “RPCRT4.dll” discarded by /OPT:REF
I imagine you’ll want to turn on RTTI in your Release build to lose the dodgy dynamic_cast warning. I usually forget this too.
Wouldn’t worry about the others. Just optimisations.
Wonderful Karbon!!!
It solved also the crash problem when closing the edit view.
Thanx a lot
I need to implement a dB scale in a rotary slider, for example between -90dB and +6dB.
I don’t understand how to use proportionOfLengthToValue() and valueToProportionOfLength(), if they perform this task.
Ad what about skewFactor()?
thanx
best regards
You can just to set your slider to move between -90 and +6, and use setSkewFactor (1.5 or so) to skew it a bit towards the higher numbers. Probably no need to use proportionOfLengthToValue() or valueToProportionOfLength().
I would like to thank Jules and all the guys here that helped me in this project. Without your support and your fast aswers to my questions I could not finish the work.
mmh interesting…
so for having parameter in 0…1 format to multiply the buffers in the inner loop:
outbuff++ = in++ * gain;
you can’t just cook it like:
gain = gainSlider->getValue();cause it will return a gain of -30.0 for example. you have to reshape the value between the slider min…max manually (and for a plugin with 200 parameters to be cooked manually is a pain in the ass)…
what about thinking a class that acts as translator ? in some projects of mine i have for every control that act as a parameter a translator which let you map the values with different mapping formulas… you want a parameter who is logaritmically expanded (like a gain one) so u assign a logaritmic GenericToRealTranslator to that slider and then set and get values in Generic (0…1) format or in Real (min…max) format, taking into account the mapping formulas.
for example:
// interface
class GenericToRealTranslator
{
public:
virtual ~GenericToRealTranslator() {}
virtual float TranslateGenericToReal(float generic) = 0;
virtual float TranslateRealToGeneric(float real) = 0;
protected:
GenericToRealTranslator() {}
};
//implementation example
class Log_GenericToRealTranslator : public GenericToRealTranslator
{
public:
Log_GenericToRealTranslator(float min, float max)
: m_min(min), m_max(max), m_expMin( log10f(m_min) ), m_expMax( log10f(m_max) )
{
}
// GenericToRealTranslator methods:
float TranslateGenericToReal(float generic)
{
const float logdata = (generic * (m_expMax-m_expMin)) + m_expMin;
generic = xStd::Pow( 10.0f, logdata );
if( generic < m_min ) generic = m_min;
if( generic > m_max ) generic = m_max;
return (float)generic;
}
float TranslateRealToGeneric(float real)
{
return (float) ((exp(real)-m_expMin)/(m_expMax-m_expMin));
}
private:
const float m_min;
const float m_max;
const float m_expMin;
const float m_expMax;
};
so for every parameter that a component is tweaking u have a generic value, a real value and a mapping formula to do conversion between types. so u can add more translator for linear, exponential, logaritmic, and even use whatever mapping formula u need, and even change it on the fly…
this is a clear method of having a slider value directly be used in the audio inner loop code without thinking too much to the conversion.
any ideas ?
lou
or, you could subclass the slider and add a ‘getNormalisedFloatValue()’ function, which would do the conversion for you too. You have to think about the calculation at some point to implement it, and the only time it matters is when it’s being relayed to the user (i.e. it’s only relevant to the control itself); therefore, it may as well be part of the control.