@Hugo-Legrand thanks, thats from the creb library. and i need to start the metro first

@Hugo-Legrand thanks for the video, very nice. somehow it didnt work like that for me, perhaps because i had to find a library for count and creb is the wrong one? that was the only missing object. or it replaced another object with something from a different library?

@Hugo-Legrand Thats very nice, also that its now posibble to change the rules on the fly or sequence them. Is it that it draws the first iteration of the left pattern into the right screen? and how big is the left drawing area?

hi @reflect_, you can do that with [unpack f f f f f f f f].

@cuinjune hi, @ingox worked with me on the one abstraction per cord solution. its still buggy but so you can get an idea if our concept makes sense or not. Mainly the communication between cord and modules seems difficult, especially if i save and reopen the patch, because $0 is renewed.
its without (mouse)cord selection and deletion and without dynamically patching the pure data connections yet, but that should be possible if the communication works well (which seems tricky, if possible at all, with dynamic patching).
the idea of iemguts canvasindex was that only the newest cord gets deleted if i release a cord outside of an input, but i think that should be possible with vanilla too.
edit: we are working on another one abstraction per cord solution.
drag_v0.3i.zip

@weightless i only implemented the multislider as a more complex interface element so far, but i would definitely say yes, they are much faster because the lissajous figures are quite complex and run very smooth. of course, like data structures, they need some extra work.

@cuinjune thanks for your thoughts. i will think about the send and receive method and saving the connections as arguments. here is a different approach with canvasindex from iemguts. depending on the method the object id could be useful.
perhaps i need to create a new abstraction for every connection (a line with an invisible rectangle around, so that its possible to select it with help of ofIsPointInsidePath). That could also mean that its easy to disconnect the pure data cord together with deleting the abstraction (the disconnect values could be saved as arguments). with this method the connections are automatically saved together with the modules. it would be nice if you inside the ofelia window, like in pure data edit mode, first click on a cord, then it gets colored or bold, and then you can delete the cord and disconnect the pure data cord with del, but thats another problem.
connect.pd

@LiamG not ignorant at all i think you are right, you can achieve the same result with toggles and dynamic patching. i think we even started to patch with the toggle method before discovering data structures. i think data structures are still a little bit more efficient than toggles, but maybe i am wrong. they store the graphical and the visual representation at once and they can work like an array and each field is one element of the array. perhaps they are also more efficient because they carry less information, its only a pixel at a position with a color. we were exploring data structures at that time and the graphical side of the patch is roughly based on https://forum.pdpatchrepo.info/topic/10734/vanilla-struct-sequencer that lead to https://forum.pdpatchrepo.info/topic/11012/grid-multi-pattern-step-sequencer-abstraction so we already had a visual grid to base the patch on.

@cuinjune thanks. i am sure the overlapping problem is solvable, i think i need to change the mouse behaviour of the gui templates (for me) for that case. i am also quite positive with the results so far, and motivated to try further. somehow i needed to change every loadbang to ofWindowLoadBang to make the dynamic patching work (?). now it makes really sense, like you mentioned earlier, to think about a concept i have some ideas, but what i definitely would like is if everybody could put their own modules easily inside kind of a template and connect them with others. also if there should be something like a main mixer or sequencer is a question for me. or if i want a "reason like" rack or more like a modular interface or something else. also saving is a good question. it would be nice if it is possible to save globally and locally, so that there are presets for a global setting that can also save the local settings of the modules. saving them as patches sounds like a good idea. i think about four module categories: instruments, effects, sequencer and visualizer or something between them. and analog to pure data, it would make sense to have audio and control connections seperated. i think more difficult than creating and destroying modules with dynamic patching is creating cord connections with dynamic patching, but perhaps also solvable because there is a fixed number of objects in every module. so maybe, theoretically one just needs the module id and the module and input output number and then it could work with the connect and disconnect message. i am not sure if i think too far with the concept, the initial idea was more to create some modules, connect them and see what happens

@cuinjune the new objects are very helpful. here is a demo how the dynamic patching could work:
drag_v0.3e.zip