Consolidate HOA_UGENS into one build target

[jamshark70]

My goodness, that is a lot of build targets.

1. Should HOA be off by default?

2. Or, can they be consolidated into fewer targets? I don't see why 1 .cpp must = 1 target.

[LFSaw]

+1

[sonoro1234]

+1

[gusano]

Option 1 would be a one-liner

[dyfer]

I personally don't use them, but in case they are set to off by default in CMakeLists, I'd consider explicitly turning them on in Travis/AppVeyor, for people depending on prebuilt packages (though I might not have full picture here)

[mossheim]

if we are going to start turning things off by default in sc3-plugins, what exactly is the point of having it here in the first place? IMO let's not complicate this repo by adding yet more configurability.

[jamshark70]

IMO let's not complicate this repo by adding yet more configurability.

There's already a configuration switch for HOA -- I'm not proposing to add configurability. But the build is a lot heavier with them enabled, and I guess they won't be as widely used as other plugins, so it may be legit to spare users the trouble of discovering independently that HOA makes the build take a lot longer.

Or let's not overlook something I said at the beginning: "Or, can they be consolidated into fewer targets? I don't see why 1 .cpp must = 1 target." I'd prefer this solution over disabling plugins actually.

[mossheim]

it's documentation and configuration overhead to suddenly turn off one target by default when all the others are on. that's all i mean. if you want to spare users the trouble of building it, move it out of this repo altogether.

the other suggestion you made works for me, feel free to implement it or maybe @florian-grond can do it since he is the original author.

[florian-grond]

What is the state of the cookie-cutter? We could possibly transfer the HOA into the cookie cutter mold. Patrick, would you be up for this? take the lead on this one? Best, Florian https://www.linkedin.com/in/floriangrond/

…

On Wed, Apr 8, 2020 at 12:55 AM Brian Heim ***@***.***> wrote: it's documentation and configuration overhead to suddenly turn off one target by default when all the others are on. that's all i mean. if you want to spare users the trouble of building it, move it out of this repo altogether. the other suggestion you made works for me, feel free to implement it or maybe @florian-grond <https://github.com/florian-grond> can do it since he is the original author. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#258 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKUTRTSZ5AOM3EJKUEYUD3RLP7SRANCNFSM4HN3NRGA> .

[mossheim]

@florian-grond the way i see it, your plugins are your responsibility. patrick may have helped initially get them into sc3plugins but that doesn't mean he is on the hook for all future maintainance. of course people should feel free to ask questions and help one another, but imo the spirit and design of this repo is very much to treat the code as semi-autonomous modules, over which each author or group of authors maintains control.

the cookie cutter repo is not intended for the task of migrating plugins, but rather for setting up new plugins from scratch. however, i have written a set of independent scripts under tools in the supercollider repo that transform a set of source files into a self contained plugin repo. if you would like to use them, i would encourage you to check their documentation and let me know if you have any questions.

[florian-grond]

That's a fair point, Brian. I am not fully up to date with the sc3-plugins future policy. I had discussed some time ago with Patrick, that the cookie-cutter approach could possibly be a good option for HOA for various reasons. I do completely agree that the current state of the SC3-plugins is complicated to say the least, my understanding of the cookie-cutter approach was to tease things apart in order to make it lighter. I believe, but might be wrong, that Patrick is still involved in SC projects with a more institutional backing where the HOA plugins play a vital role, at least in the beginning. This is why I was reaching out to Patrick. But of course, Patrick/nobody should feel obliged or pressured in any way. I just recently received a message from an SC-HOA user about how useful the repo is, but I must admit I have very little time atm to put in. Best, Florian https://www.linkedin.com/in/floriangrond/

…

On Wed, Apr 8, 2020 at 12:08 PM Brian Heim ***@***.***> wrote: @florian-grond <https://github.com/florian-grond> the way i see it, your plugins are your responsibility. patrick may have helped initially get them into sc3plugins but that doesn't mean he is on the hook for all future maintainance. of course people should feel free to ask questions and help one another, but imo the spirit and design of this repo is very much to treat the code as semi-autonomous modules, over which each author or group of authors maintains control. the cookie cutter repo is not intended for the task of migrating plugins, but rather for setting up new plugins from scratch. however, i have written a set of independent scripts under tools in the supercollider repo that transform a set of source files into a self contained plugin repo. if you would like to use them, i would encourage you to check their documentation and let me know if you have any questions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#258 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKUTRSG6IDHU7BXGQFSWCTRLSOQ3ANCNFSM4HN3NRGA> .

[patrickdupuis]

I believe, but might be wrong, that Patrick is still involved in SC
projects with a more institutional backing where the HOA plugins play a
vital role, at least in the beginning. This is why I was reaching out to
Patrick.

What are you saying? I am paid to work on SC? That is not true and you know it. We have worked on SC quarks together at the same art centre. That is not to say that we contribute to SC with "financial backing". When I contribute to SC, I do so on my own time. Please stop spreading this idea that I work for you, or that I am funded to work on SC.

[florian-grond]

Hi Patrick, I am very sorry this was wrongly received. Patrick, I know that you are not paid for your important voluntary SC dev work. What I meant was that if the art center (which has an emphasis on open source from what I know, has an interest in having SC-HOA as part of SC3-plugins, then maybe we can discuss together on how to do that best. I have no idea, maybe this is also not the place to discuss it here but at the same time it kind of impacts more than just you or me and the places where we work and whether they pay us for our SC involvement. We did have the cookie-cutter SC-HOA conversation about less than a year ago. Also, I got various merge requests in the past, which gave me the impression that it is vital for the work in the center. I have only limited time to put in in the foreseeable future and if the devs community decides to remove SC-HOA from the SC3-plugins because it is OFF by default (which in fact would be unsatisfying in the long run) then I will think it is unfortunate because people are using it but I cannot maintain it on my own. I hope I did not step on anyone's toes! Let me know your thoughts, Florian https://www.linkedin.com/in/floriangrond/

…

On Wed, Apr 8, 2020 at 2:32 PM Patrick Dupuis ***@***.***> wrote: I believe, but might be wrong, that Patrick is still involved in SC projects with a more institutional backing where the HOA plugins play a vital role, at least in the beginning. This is why I was reaching out to Patrick. What are you saying? I am paid to work on SC? That is not true and you know it. We have worked on SC quarks together at the same art centre. That is not to say that we contribute to SC with "financial backing". When I contribute to SC, I do so on my own time. Please stop spreading this idea that I work for you, or that I am funded to work on SC. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#258 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKUTRQQTF3W64FET7XP6BTRLS7M7ANCNFSM4HN3NRGA> .

[jamshark70]

Changed the title because... wow, did that ever go off the rails.

My concern is only that the current setup of the HOA plugins makes it hard to estimate build progress, as it struck me that there are a ton of distinct build targets (seemingly one per source file). There's no other plugin set that generates so much build output. mainly that it seems like HOA build time is disproportionate to the rest of the project, but (see below) it's not really insane.

I never meant to suggest that the plugins should be removed.

Brian, you know that I don't know anything about cmake, and you know that I have other pressures going on in my life at the moment. I don't have bandwidth to get myself up to speed on cmake by myself, so I'm not able to prepare any prs without guidance.

So I suppose the best course of action at this point is to close the ticket and leave it as it is.