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 [email protected] 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 https://github.com/supercollider/sc3-plugins/issues/258#issuecomment-610750710, 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 [email protected] 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 https://github.com/supercollider/sc3-plugins/issues/258#issuecomment-611048250, 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 [email protected] 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 https://github.com/supercollider/sc3-plugins/issues/258#issuecomment-611120613, 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.

[jamshark70]

OK, let's put some facts on it:

(
f = { |cmd|
	var now = Main.elapsedTime,
	pid = cmd.unixCmd { |exit|
		"Command exited with % and took % seconds\n".postf(exit, Main.elapsedTime - now);
	};
};
)

// in Terminal, `make clean` before this
f.("cd /home/dlm/share/sc3-plugs-hjh/build18-0131 && make");
... snip
Command exited with 0 and took 386.581266785 seconds

// in Terminal, `cmake .. -DHOA_UGENS=ON` before this
f.("cd /home/dlm/share/sc3-plugs-hjh/build18-0131 && make");
... snip
Command exited with 0 and took 446.232555909 seconds

• Looking at it negatively: HOA is 446 / (446+368) = 53% of the build time (!), and is unlikely to be used as often as, say, DWG units or the more exotic filters (since ambisonics tend to assume that you have a speaker array, and most users, including myself, don't). So we could save time for people who are building from source (such as, all Linux users) by turning them off by default and documenting how users can turn them on if they need them (also saving CPU power consumption).

• Looking at it positively: It's only 7.5 minutes -- it's not really that bad.

At this point, on balance, the 7.5 minutes isn't worth the surprisingly negative direction that this conversation has taken. I'll leave the issue open in case someone else is interested, but... probably better to close.

[redFrik]

and, if things hasn't drastically changed since feb2018, i couldn't figure out how to compile HOAUgens natively at all on Raspberry Pi - the third most popular OS according to the survey. not even with extra swap memory. so i vote for leaving it OFF by default.

[dyfer]

When things are being built from source, what is the issue of turning a given cmake option OFF manually?

[redFrik]

the issue is 'only' that it needs to be clearly documented. https://github.com/supercollider/sc3-plugins is already pretty dense.

[dvzrv]

Hi! I would like to chime in and say that I would like to have all plugins in sc3-plugins buildable by default if possible.

I don't think that disabling them by default is a good idea (will lead to bit rot).

I think a way forward will be to improve documentation and improve the cmake setup of this repository (I know it's a bit messy, but that's also true for SuperCollider's).

@redFrik could you open or link to a ticket that tracks the problems on building the HOAUgens on Raspberry Pi?

[redFrik]

i was wrong. The HOAUgens _do compile. At least under latest raspbian buster on a RPi3 with 1Gb ram. Building just takes a long time.

atm i can't test if it is working on an older/smaller single core RPi (2, 1 or zero) - they typically have half the amount of ram.

IIRC building with hoa enabled used to run out of memory and crash the compiler. But it must have been under raspbian stretch with the older gcc then.

Good point about bit rot David. And if, as it looks, RPi can compile the HOAUgens, i no longer mind leaving them ON by default.

[florian-grond]

The HOAUgens did compile on the RPi3 in the past except for one very heavy Ugen (binauralizer with a linear convolution build in Faust) so we had decided to remove this one from the collection. But as you say it still takes a very long time.

Binauralization is now differently implemented and still available.

As RPi3 is less likely to do heavy-duty multichannel higher-order Ambisonics this was one of the reasons we considered to move it out into the cookie-cutter ... where we could decide to only serve platforms where it makes the most sense, and others need to be compiled by the users themselves.

https://www.linkedin.com/in/floriangrond/

On Thu, Apr 9, 2020 at 8:02 AM redFrik [email protected] wrote:

i was wrong. The HOAUgens _do compile. At least under latest raspbian buster on a RPi3 with 1Gb ram. Building just takes a long time.

atm i can't test if it is working on an older/smaller single core RPi (2, 1 or zero) - they typically have half the amount of ram.

IIRC building with hoa enabled used to run out of memory and crash the compiler. But it must have been under raspbian stretch with the older gcc then.

Good point about bit rot David. And if, as it looks, RPi can compile the HOAUgens, i no longer mind leaving them ON by default.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/supercollider/sc3-plugins/issues/258#issuecomment-611490689, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKUTRRM3RRWH5JILJ6ASUDRLW2NHANCNFSM4HN3NRGA .

[dyfer]

the issue is 'only' that it needs to be clearly documented. https://github.com/supercollider/sc3-plugins is already pretty dense.

All right, that's clear then. Let's focus on documenting cmake options. Currently, I can see only a few ugen-related flags in cmake (AY, HOA_UGENS and NOVA_DISK_IO). Here are all basic CMake options on my system:

 AY                               ON
 CMAKE_BUILD_TYPE
 CMAKE_INSTALL_PREFIX             /usr/local
 CMAKE_OSX_ARCHITECTURES
 CMAKE_OSX_DEPLOYMENT_TARGET
 CMAKE_OSX_SYSROOT
 CPP11                            ON
 HOA_UGENS                        ON
 IN_PLACE_BUILD                   ON
 NATIVE                           OFF
 NOVA_DISK_IO                     OFF
 NOVA_SIMD                        ON
 OSX_PACKAGE                      OFF
 QUARKS                           OFF
 SC_PATH                          /path/to/src/supercollider
 SUPERNOVA                        ON
 SYSTEM_STK                       OFF

I think just documenting these in the readme would be enough for anyone to turn them off if needed.