Algorithm FM tear down

[pongasoft]

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

[jam-s]

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.

[orthodox]

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.

[rcbuse]

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

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:

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",
      .......
        

Now 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.

[pongasoft]

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

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:

Code: Select all

      .......
        

Now 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.

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

[orthodox]

* 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).

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.

* 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

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.

* I cannot modify this value from the C++ code

Correct. If you can change it from GUI, it must be "document_owner" or "gui_owner", and you can't change those from C++.

[rcbuse]

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

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.

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.