@cuinjune hello, i expanded the vslider with a jump on click argument, there you can toggle between jump on click and continuous.
vslider2.pd for the others: if you want to use this slider/abstraction you need to put it into the folder ofelia/examples/gui/pdgui

@Jona Wow, I didn't know interpolation on the y axis was also needed but now it seems to work much more accurately. Thank you for your work. I think it will be very useful.

here is a little sequencermod of the multislider (just a basic mechanism):
mslider_seqmod.pd
pdguiExampleMsliderSeqMod.pd
and here the slightly modified synth from Max Björverud: Additiv-syntes.pd
mslider_seqmod and Additiv-syntes need to be put into the folder ofelia/examples/gui/pdgui and pdguiExampleMsliderSeqMod into ofelia/examples/gui

@Jona Nice sequencer! I couldn't hear the sound because I don't have [Additiv-syntes] abstraction. I think one would be able to easily create some interesting polyrhythmic sequences using them.

@cuinjune sorry, i forgot to add the synth patch. [Additiv-syntes] is this synth from Max Björverud (slightly modificated, i will upload it later): https://patchstorage.com/additive-synthesis/ i have some ideas for generating (poly)rhythm and melody, saving and sequencing patterns that i want to implement. some more general things: it would be nice if it is possible to type numbers into the numbox, like in pure data. and i was wondering if its possible to continue the audio stream if you drag the ofWindow in "pure data mode" (like it works as a standalone application / does not matter if it is not possible). i was thinking about modularity and ofelia and had the idea of making more complex gui objects like sequencer or synth modules that are draggable and connectable (with fake patch cords ?), also "dynamic patching" could be nice, so that it is possible to create and destroy modules. another way would be to use several standalone applications and make them communicate via osc or midi (but then its not possible to pass audio signals from one application to another). it would be very nice to use the ofelia gui elements as "gop`s" inside pure data, but i know its not possible. or the best concept is perhaps to to use ofelia to build stand alone applications where the connection between modules is fixed and everything happens in one window (like a "groovebox") or just to create visuals like with gem? i am not sure if it makes sense, just some brainstorming

@Jona Hi, I just added the feature to [numbox] as it didn't sound too difficult to implement one. numbox.pd
Thank you for your suggestion. I will add this change officially once it seems to be working stably. Let me know if you find any problem using it.

It is not possible(and won't be anytime soon) to continue the audio stream while resizing the window. What you can do instead is using the hotkey Ctrl -/+ which also resizes the window.

Creating draggable and patchable synth modules sounds very interesting although it will be a huge amount of work. Maybe you're thinking something like a Nord Modular or a Reaktor? I also once thought about creating a patchable environment in ofelia via dynamic patching. But there will be so many problems to solve like how to accurately keep track of objects and connections, how to deal with patch saving and loading and so on.. But I'm still keen on finding the good solution.

It will be a lot easier if you allow users to create a limited number of modules so you don't have to dynamically create/destroy modules and each module can have its own unique ID so you can make a connection using it. And even easier if you have a fixed number of modules like Korg MS-20 since you only need to deal with connections of patch cords and parameters of the module. And the easiest would be to create something like a groovebox or a synth which has a fixed internal connection and all you need is to handle the existing parameters.

Thanks for reminding me this. I will think about the ways to create patchable environment again soon. (although there's no guarantee of finding the solution)

@cuinjune hi. thanks for the numbox update and your explanations. yes, i was thinking about something like reaktor, but i think i understand the difficulties and limitations. still great possibilities and advantages with the ofelia gui

@ingox and me tried to make the gui elements draggable. it works nice so far, but is very experimental. it would be nice to solve the issue with the render order, so that the dragged object is always in the foreground, we tried that with "ofSetDepthTest ON" but it was too complicated to adjust the z axis for different layers. another issue is that ofIsPointInsidePath selects both elements if they are on top of each other, so dragging can change the values of the elements below.
drag_main, synth2, and ctrl need to be put in ofelia/examples/gui and mslider_seqmod, Additiv-syntes and vslider2 into ofelia/examples/gui/pdgui
drag.zip

@Jona Hi, nice work! Do you want to make the dragged object to appear on top or do you want to make the object that appears on top first draggable? Or maybe both?

What should happen when you drag the overlapped area of 2 or more objects?

I think it's possible to do it by changing rendering order of [ofHead] and there are [ofGetFirstRenderOrder] and [ofGetLastRenderOrder] which can be used to make specific drawing to appear on the background or foreground.

@cuinjune Hi I quickly created an example patch that may be helpful to you.

draggableShapes.pd

It's a simple example of dragging around different shapes.
The shape that shows up more front will have a higher priority for selection.
You will also see some comments I wrote on the patch.

I hope this helps and let me know if you have any questions.

Note: although I used [ofGetLastRenderOrder] in subpatches, It's not necessary in this case since the lastly created [ofHead] will be rendered later(front) anyway if multiple [ofHead]s use the same render order.

@cuinjune thanks a lot for the patch. i think the ideal solution would be that the dragged object appears on top, and that only the upper object is draggable when there is overlapping (like in your patch). the dragged object could get the last render order, and the one dragged before last render order -1, and that one dragged before last render order -2 and so on... it would be very nice too if the values of the lower gui objects are not affected from the mouse movement on an upper object. i will think about a solution.

@Jona Maybe this is what you want? draggableShapes2.pd

@cuinjune yes, exactly. thanks. drag_v0.1.zip

@Jona Impressive! I had fun playing with the patch.
Here's another example I made draggableShapes.zip to demonstrate how it can be done using abstraction.

You will be able to dynamically create shapes(modules) through this approach although I'm not sure how to save position of the modules and how to delete the abstraction dynamically in vanilla pd. Anyways, I hope this helps!

@cuinjune thanks. this video (not mine) could show the vanilla solution for dynamically deleting abstractions (actually not the video itself but the comment below: "UPDATE: I've found a way to delete specific objects. You can use the internal message "pd-name-of-subpatch mouse x y 0 0" to click on parts of the patch, then use "pd-name-of-subpatch cut" to delete the object. This is ever better than "click" because it doesn't focus the window while it's happening."):

but its not a problem if i need to use externals. for saving the position it would be nice to update the position arguments while the object is dragged, but perhaps thats not possible. i will think about it.

@cuinjune i implemented the patch draggableShapes, it works very well, thanks. and i implemented an osc module
it would be nice if an area of interface elements not reacts if there is another element in front, i think it should be possible with ofIsPointInsidePath and i can solve it. edit: now with right audio channel.
drag_v0.2.zip

@Jona Looks great! Yes it should be possible. But I think you would need to replace [ofTouchListener] with [_locRcv]s to listen to the event from the main patch so the module interface can listen to the mouse click according to the render order. (Just like how it's done with draggableShapes example)

[_locRcv] should be used one level lower from the main patch. This is to use main patch's local variable name and still communicate with other abstractions. Also note if you use [ofMouseListener], it will not handle multitouch on mobile devices. (it will respond to one finger at a time) That's why I used [ofTouchListener] in pdgui abstraction. But if you're targeting desktop only, [ofMouseListener] is enough and easier to handle.

If you really want to build the modular environment using multiple modules, I suggest you first consider how each module should work commonly and try to first build a minimal module that only has common attributes. (e.g. window bar, interface section, render order..) Then it would be easier to maintain and to create other module later on since you only need to add the non-common part on top of your minimal module.

I think creating such large system requires thorough planning and clear idea of how things should work in the first place otherwise it is likely that you will continuously face many unexpected problems and have to rework many times.

P.S.: You probably know this but your patch currently uses left audio channel only.

@cuinjune thanks a lot for the new ofelia update. with the method from @Johnny-Mauser https://forum.pdpatchrepo.info/topic/8698/renaming-abstraction-objects/4 i found a nice way to store the position within the main patch.
drag_v0.3.zip
and here is a very first attempt to draw cords between two points: cords.pd

@Jona Nice trick! I think you should also save the render order btw.
And interesting to see the patch cords demo.

I will consider adding the object that can change abstraction's arguments. It can be called something like [ofSetDollarArgs] I think.

I will inform you if I make any progress.

@cuinjune something like ofSetDollarArgs sounds very useful. it should also save the render order now (i dont know if its the best way, but it seems to work): drag_v0.3b.zip

@Jona Nice work! I just made the following changes to ofelia. (Not uploaded to Deken yet.)

• renamed [ofGetDollarArgs] to [ofGetCanvasArgs]
• added [ofSetCanvasArgs] and [ofRemoveCanvas]

The new [ofGetCanvasArgs] and [ofSetCanvasArgs] allow you to get/set the creation arguments of the subpatch or abstraction. So I renamed it to "canvas args" because it also works with the subpatches too. And with [ofRemoveCanvas], you can remove the subpatch or abstraction by sending 'bang' to the object.

Using these objects, you'll be able to dynamically create/change arguments/remove abstractions more easily. You can do this on a separate empty pd patch so you can save/open patches for your modules.

I'm planning to upload v1.0.8 binary in a week or two with a few more updates.
But you can download and build the external yourself using the lastest master branch from https://github.com/cuinjune/ofxOfelia.
Or just let me know if you want me to quickly build and send you the current v1.0.8 external file for Windows.