I constructed a simple class SinOscillator to calculate one sinewave. After that I constructed a class MultiSin containing 4 x SinOscillator with f, f*2, f*3, f*4 (a kind of simple Hammond). This works fine.
After that I constructed within the main plugin 2 x MultiSin to have more than one note, lets say you play a C and an G. But now it seems that the 2 MultiSin use the same SinOscillator set. (The played notes are not C and G but one single note 2.5 times higher than C ).
What is necessary to have a correct MultiSin[index1]SinOscillator[index2] adressing ?? And by the way, is it possible to have indexed user control variables for the faders (e.g. m_fMyVariable[index] ) ??
Many thanks for your help.
I have created a simple plug-in that replicates what you are trying to do (link is at the end of this reply). I use forwarding functions to set the parameters but it looks like you want to access each sine component individually. I put both ways of doing this so check the code carefully.
// in MultiSine.h
// array of four
// in the plug_in.h
// in userInterfaceChange() as an example:
As for your question on indexing variables; you can do this indirectly by using the RackAFX linked list of GUI control objects. Each GUI control (slider, button) on the UI is indexed from 0->39 for the sliders and 41-44 for the button banks). This ID value is also shown at the top of the table when you setup a slider.
Each control is encapsulated in a CUICtrl object. These are then stored in a linked list in the plugin object. The CUICtrl object has a pointer to your member variable and uses this to change the value as the user moves the slider. You can access this pointer and de-reference it to use it. For example in userInterfaceChange again, and using my method of calling one function that internally sets the 4 frequencies:
// accessing the m_fOsc2Fo with an index from the UIControl array
// get the pointer; I know it is slider #1
CUICtrl* pUICtrl = getUICtrlByControlID(1);
// check to make sure its valid before using, just to make sure...
// use it by de-referencing the Cooked data
You can get the whole plug-in project here:
thanks - now my project works. (I used the Gordon-Smith Oscillator as a simple solution). All I had to do is to move my function definitions from the .cpp to the correspondent .h file and declare them as inline. Likewise I moved the multiple sine object declaration from the .cpp to the .h file. I do not understand this completely but I am very happy with this solution. The inline declaration generates much lesser CPU load now.
It should not make a difference whether the functions are inline in the .h file or in the .cpp file as far as functionality goes.
However, the member object declarations (multi-sine object) *must* be in the .h file. That is the original source of your problem.
Also, remember to compile in Release mode (after you debug) as this will greatly reduce CPU load.
Most Users Ever Online: 152
Currently Browsing this Page:
Guest Posters: 1
Newest Members:Jas, Rowan, sojourn, fabhenr, rg1, Niklas, Wutru, Tim Campbell, Danny Jonel, Valentin
Moderators: W Pirkle: 573
Administrators: Tom: 74, JD Young: 80, Will Pirkle: 0, W Pirkle: 573, VariableCook: 3