Algorithm FM tear down

This forum is for developers of Rack Extensions to discuss the RE SDK, share code, and offer tips to other developers.
User avatar
pongasoft
RE Developer
Posts: 290
Joined: 21 Apr 2016
Location: Las Vegas

Post 25 Feb 2021

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

User avatar
jam-s
Posts: 1312
Joined: 17 Apr 2015
Location: Aachen, Germany

Post 25 Feb 2021

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.
If you're in Aachen, come and visit us at the Voidspace. ... Pool's closed due to corona.

User avatar
orthodox
RE Developer
Posts: 1365
Joined: 22 Jan 2015

Post 25 Feb 2021

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.
Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise. -- L.Carroll

User avatar
rcbuse
RE Developer
Posts: 941
Joined: 16 Jan 2015
Location: SR388

Post 25 Feb 2021

pongasoft wrote:
25 Feb 2021
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.

User avatar
pongasoft
RE Developer
Posts: 290
Joined: 21 Apr 2016
Location: Las Vegas

Post 26 Feb 2021

rcbuse wrote:
25 Feb 2021
pongasoft wrote:
25 Feb 2021
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

User avatar
orthodox
RE Developer
Posts: 1365
Joined: 22 Jan 2015

Post 26 Feb 2021

pongasoft wrote:
26 Feb 2021
* 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.
pongasoft wrote:
26 Feb 2021
* 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.
pongasoft wrote:
26 Feb 2021
* 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++.
Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise. -- L.Carroll

User avatar
rcbuse
RE Developer
Posts: 941
Joined: 16 Jan 2015
Location: SR388

Post 26 Feb 2021

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

  • Information
  • Who is online

    Users browsing this forum: CommonCrawl [Bot] and 0 guests