I know it probably won't happen, but I would love to have the devs that worked on Algorithm FM do a quick run down of the technology. I am not talking about source code, but more like what challenges they faced implementing this device, where did they use custom displays, how did they implement "random" (this is something I have been struggling with since for example, if a knob is a owned by "document" then the "rt" (= c++) cannot change it, so how do you do it?).
That would be very useful to all developers to get this kind of insights to incorporate in their future products...
Yan
Algorithm FM tear down
To me it looks like the whole middle section of the synth is a custom display widget (much like with complex-1 in cable edit mode). Then there's the mod matrix bottom left and changing panels on the bottom right and normal controls on the top bar.
Just making the Randomizer slider a custom display will do the job, if you pass all the randomized properties as parameters to the gesture handler.
The remaining custom displays are the cable editor and the mod matrix, I guess. No more custom displays is needed.
EDIT: I forgot the LFO/Curves display.
The remaining custom displays are the cable editor and the mod matrix, I guess. No more custom displays is needed.
EDIT: I forgot the LFO/Curves display.
If you want to random the whole patch, you need to have a custom display that uses all the parameters.. the list will be huge. The code is from Nostromo:pongasoft wrote: ↑25 Feb 2021I know it probably won't happen, but I would love to have the devs that worked on Algorithm FM do a quick run down of the technology. I am not talking about source code, but more like what challenges they faced implementing this device, where did they use custom displays, how did they implement "random" (this is something I have been struggling with since for example, if a knob is a owned by "document" then the "rt" (= c++) cannot change it, so how do you do it?).
That would be very useful to all developers to get this kind of insights to incorporate in their future products...
Yan
Code: Select all
jbox.custom_display{ graphics={ node="PatchRandomCD", },
background = jbox.image{path = "CustomDisplayButtonRandom"},
display_width_pixels = 19, display_height_pixels = 19, draw_function="draw", gesture_function="gesture", invalidate_function="invalidate", show_remote_box=false, show_automation_rect=false,
values={
"/custom_properties/rand_type",
"/custom_properties/rand_sections",
"/custom_properties/rand_amount",
"/custom_properties/rand_complex",
"/custom_properties/rand_src",
"/custom_properties/rand_scale",
"/custom_properties/rand_dst",
"/custom_properties/rand_menu_latch",
"/custom_properties/osc_1_voices",
"/custom_properties/osc_1_keyboard_tracking",
"/custom_properties/osc_1_octave",
"/custom_properties/osc_1_semitone",
"/custom_properties/osc_1_cents",
"/custom_properties/osc_1_voice_detune",
"/custom_properties/osc_1_key_sync",
"/custom_properties/osc_1_wave_crossfade",
"/custom_properties/osc_1_pan",
"/custom_properties/osc_1_voice_spread_width",
"/custom_properties/osc_1_level",
"/custom_properties/osc_1_filter_select",
"/custom_properties/osc_1_wave_1",
"/custom_properties/osc_1_wave_2",
"/custom_properties/osc_1_wave_3",
"/custom_properties/osc_1_wave_4",
"/custom_properties/osc_1_wave_5",
.......
Thank you for sharing your example. I just want to confirm that I understand correctly:rcbuse wrote: ↑25 Feb 2021If you want to random the whole patch, you need to have a custom display that uses all the parameters.. the list will be huge. The code is from Nostromo:pongasoft wrote: ↑25 Feb 2021I know it probably won't happen, but I would love to have the devs that worked on Algorithm FM do a quick run down of the technology. I am not talking about source code, but more like what challenges they faced implementing this device, where did they use custom displays, how did they implement "random" (this is something I have been struggling with since for example, if a knob is a owned by "document" then the "rt" (= c++) cannot change it, so how do you do it?).
That would be very useful to all developers to get this kind of insights to incorporate in their future products...
YanNow if you want to do some kind of slider / fader like they did here, you are going to have to first store all the current vales in your on_tap handler. Store them in custom_data since that table will last the duration of your gesture. Generate some new random values on_tap as well and put those in the custom_data. Now on every on_update, you are going to have interpolate between the original values and the new values based on the slider position and store that back into propery_changes.Code: Select all
.......
* Let's say I have a "regular" volume knob, meaning it is a document owner property (ex: my_volume_knob) and is represented by a jbox.analog_knob (and I want to emphasize this, it is not represented by a custom display).
* I can then create a custom display that will have this /custom_properties/my_volume_knob set in "values" and I can modify (for example on mouse click on the custom display) it to whatever value I want
* I cannot modify this value from the C++ code
Is this correct?
Thanks
Yan
Not sure I understand what is "not represented by a custom display". The only way to "represent" a value with a custom display is to list it in jbox.custom_display.values{}, i.e. custom displays can only draw something based on those properties and change them (only "document_owner" and "gui_owner" ones).
For the rest, you can have as many GUI elements as you like, representing the same property, and they all will be able to show and change it coherently.
Strictly speaking, only to a value that you can derive from the values listed in jbox.custom_display.values, gesture parameters and constants (and Lua functions like math.random). Other property values are inaccessible even as a source.
Correct. If you can change it from GUI, it must be "document_owner" or "gui_owner", and you can't change those from C++.
That is all correct! And whatever you change the value to in the jbox.custom_display with also be reflected in the jbox.analog_knob automatically.pongasoft wrote: ↑26 Feb 2021
Thank you for sharing your example. I just want to confirm that I understand correctly:
* Let's say I have a "regular" volume knob, meaning it is a document owner property (ex: my_volume_knob) and is represented by a jbox.analog_knob (and I want to emphasize this, it is not represented by a custom display).
* I can then create a custom display that will have this /custom_properties/my_volume_knob set in "values" and I can modify (for example on mouse click on the custom display) it to whatever value I want
* I cannot modify this value from the C++ code
Is this correct?
Thanks
Yan
The _only_ way you can get a C++ rt_value into a document owned property is though a custom display interaction. And in that interaction/gesture you need to take the rt_value and save it to the property value. Thats what all the devices that record things do, and you need to click something to actually get it into the patch.
-
- Information
-
Who is online
Users browsing this forum: No registered users and 3 guests