I see your point. I think this is most useful when used for actual abstractions, this is when from within a patch you call another .pd file that represents an encapsulated patch, so you will have identical copies of the same patch. Change it once and changes apply everywhere. If you made a synth that have say 20 parameters and you really liked it, it would be nice to use it as an abstraction so that you can instance it many times from within a patch, and since it's a premade thing that's "finished" it's also nice to have the UI already built inside the abstraction to control all those parameters.
I’m just beginning to learn pure data and I’m also a software developer so I understand both your points. I think both strategies have their place. If I was designing an engine, utility or ‘core’ then I wouldn’t include the UI. However if I was designing a ‘module’ then I would look at it from a hardware modular perspective and would want the necessary UI encapsulated within the sub patch and take care that the representation looks and feels nice to the user.
Yes. I think you are right. I hadn't thought of it quite like that, but actually that's the best way to think about it. PD is potentially an excellent "virtual modular". But because you are starting from a slightly lower level, it doesn't always feel like that compared to, say, VCV Rack or similar. But actually it could / should totally be thought of in those terms. So the best thing is to use subpatches to make module-like things and then the top level is like patching them together. This definitely clarifies how to think about it for me.
Thanks for that. I've never delved into encapsulate and think maybe I should. I was about to make a video on PureData about persistence of UI values between reloads of a patch. Plus saving an loading of presets. And having the ability to keep a synth you're building in PD in sync as you're building it, since you often disconnect things and loose the value from the control when it gets disconnected and reconnected. This might be useful in that context.
That sounds pretty awesome. I have no idea how to persist values. I guess PD has the ability to write files. But is there a way to discover what the current setting of all the sliders is? Or do you have to explicitly set up routing their outputs to another recording component?
I see your point. I think this is most useful when used for actual abstractions, this is when from within a patch you call another .pd file that represents an encapsulated patch, so you will have identical copies of the same patch. Change it once and changes apply everywhere. If you made a synth that have say 20 parameters and you really liked it, it would be nice to use it as an abstraction so that you can instance it many times from within a patch, and since it's a premade thing that's "finished" it's also nice to have the UI already built inside the abstraction to control all those parameters.
I’m just beginning to learn pure data and I’m also a software developer so I understand both your points. I think both strategies have their place. If I was designing an engine, utility or ‘core’ then I wouldn’t include the UI. However if I was designing a ‘module’ then I would look at it from a hardware modular perspective and would want the necessary UI encapsulated within the sub patch and take care that the representation looks and feels nice to the user.
Yes. I think you are right. I hadn't thought of it quite like that, but actually that's the best way to think about it. PD is potentially an excellent "virtual modular". But because you are starting from a slightly lower level, it doesn't always feel like that compared to, say, VCV Rack or similar.
But actually it could / should totally be thought of in those terms.
So the best thing is to use subpatches to make module-like things and then the top level is like patching them together.
This definitely clarifies how to think about it for me.
Thanks for that. I've never delved into encapsulate and think maybe I should. I was about to make a video on PureData about persistence of UI values between reloads of a patch. Plus saving an loading of presets. And having the ability to keep a synth you're building in PD in sync as you're building it, since you often disconnect things and loose the value from the control when it gets disconnected and reconnected. This might be useful in that context.
That sounds pretty awesome. I have no idea how to persist values. I guess PD has the ability to write files. But is there a way to discover what the current setting of all the sliders is? Or do you have to explicitly set up routing their outputs to another recording component?
@@synaesmedia you got to build a circuit for it. You'll see you when I get my video together.