I think a first step could be to make all opcodes in /Opcodes plugins, keeping /OOps internal and see where that gets us.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 20 Dec 2022, at 17:07, John <jpff@codemist.co.uk> wrote:
>
> *Warning*
>
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>
> This is a follow-up to my paper in Athlone and various emails since.
>
> Does this sound like a way to satisfy some users?
>
> In Csound5 pre-release phase we had a Csound for which nearly all
> opcodes were plugins in libraries based on the source file structure.
> At the time too many smaller devices could not deal with loadable code
> so this approach was abandoned in favour of the current schemes in
> cs6.
>
> We could redo this, and then the size/scope of a Csound would be
> selectable.  It might need some better way of selecting which
> components are to be loaded but that can wait.
>
> One could arrange the sources to it compiled either the current scheme
> or the total-plugin idea. Fundamentally it would be two building
> systems.  Certainly would be less disturbing than Minimal7. I am not
> sure how long this would take to do but it feels straightforward.
>
> It could be the basis of all Csound7 or be a sub-case.
>
> Any thoughts or comments?
>
> ==John ffitch

Personally I would not like to see these opcodes become plugins. The current csound64 library contains pretty much all you need to build outstanding audio software. As a single library it's fantastic. I don't understand why we would choose to remove some of that functionality and place it into different plugin libraries and add further pressure on frontend developers. What is to be gained from this? In my view it makes using csound as a library far less attractive.   

csound64.dll is currently 4Mbs on Windows. How much smaller does it need to be? 

On Tue, 20 Dec 2022 at 18:09, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

I think a first step could be to make all opcodes in /Opcodes plugins, keeping /OOps internal and see where that gets us.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 20 Dec 2022, at 17:07, John <jpff@codemist.co.uk> wrote:
>
> *Warning*
>
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>
> This is a follow-up to my paper in Athlone and various emails since.
>
> Does this sound like a way to satisfy some users?
>
> In Csound5 pre-release phase we had a Csound for which nearly all
> opcodes were plugins in libraries based on the source file structure.
> At the time too many smaller devices could not deal with loadable code
> so this approach was abandoned in favour of the current schemes in
> cs6.
>
> We could redo this, and then the size/scope of a Csound would be
> selectable.  It might need some better way of selecting which
> components are to be loaded but that can wait.
>
> One could arrange the sources to it compiled either the current scheme
> or the total-plugin idea. Fundamentally it would be two building
> systems.  Certainly would be less disturbing than Minimal7. I am not
> sure how long this would take to do but it feels straightforward.
>
> It could be the basis of all Csound7 or be a sub-case.
>
> Any thoughts or comments?
>
> ==John ffitch

4Mbs is a lot on some embedded systems, and for the WASM build I would
love to make the Csound download smaller. Hlodver has done really good
work getting the size down, but it could be even smaller if there was
a way to easily remove the unused bits. Every byte counts when it
comes to web pages.

Perhaps there is some middle ground? I'm not a front-end developer, so
forgive my ignorance in asking, but what pressures would this feature
add on you?

On Tue, Dec 20, 2022 at 2:38 PM Rory Walsh <rorywalsh@ear.ie> wrote:
>
> Personally I would not like to see these opcodes become plugins. The current csound64 library contains pretty much all you need to build outstanding audio software. As a single library it's fantastic. I don't understand why we would choose to remove some of that functionality and place it into different plugin libraries and add further pressure on frontend developers. What is to be gained from this? In my view it makes using csound as a library far less attractive.
>
> csound64.dll is currently 4Mbs on Windows. How much smaller does it need to be?
>
>
>
> On Tue, 20 Dec 2022 at 18:09, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>
>> I think a first step could be to make all opcodes in /Opcodes plugins, keeping /OOps internal and see where that gets us.
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>> > On 20 Dec 2022, at 17:07, John <jpff@codemist.co.uk> wrote:
>> >
>> > *Warning*
>> >
>> > This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> >
>> > This is a follow-up to my paper in Athlone and various emails since.
>> >
>> > Does this sound like a way to satisfy some users?
>> >
>> > In Csound5 pre-release phase we had a Csound for which nearly all
>> > opcodes were plugins in libraries based on the source file structure.
>> > At the time too many smaller devices could not deal with loadable code
>> > so this approach was abandoned in favour of the current schemes in
>> > cs6.
>> >
>> > We could redo this, and then the size/scope of a Csound would be
>> > selectable.  It might need some better way of selecting which
>> > components are to be loaded but that can wait.
>> >
>> > One could arrange the sources to it compiled either the current scheme
>> > or the total-plugin idea. Fundamentally it would be two building
>> > systems.  Certainly would be less disturbing than Minimal7. I am not
>> > sure how long this would take to do but it feels straightforward.
>> >
>> > It could be the basis of all Csound7 or be a sub-case.
>> >
>> > Any thoughts or comments?
>> >
>> > ==John ffitch

4Mbs is a lot on some embedded systems, and for the WASM build I would
love to make the Csound download smaller. Hlodver has done really good
work getting the size down, but it could be even smaller if there was
a way to easily remove the unused bits. Every byte counts when it
comes to web pages.

Perhaps there is some middle ground? I'm not a front-end developer, so
forgive my ignorance in asking, but what pressures would this feature
add on you?

On Tue, Dec 20, 2022 at 2:38 PM Rory Walsh <rorywalsh@ear.ie> wrote:
>
> Personally I would not like to see these opcodes become plugins. The current csound64 library contains pretty much all you need to build outstanding audio software. As a single library it's fantastic. I don't understand why we would choose to remove some of that functionality and place it into different plugin libraries and add further pressure on frontend developers. What is to be gained from this? In my view it makes using csound as a library far less attractive.
>
> csound64.dll is currently 4Mbs on Windows. How much smaller does it need to be?
>
>
>
> On Tue, 20 Dec 2022 at 18:09, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>
>> I think a first step could be to make all opcodes in /Opcodes plugins, keeping /OOps internal and see where that gets us.
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>> > On 20 Dec 2022, at 17:07, John <jpff@codemist.co.uk> wrote:
>> >
>> > *Warning*
>> >
>> > This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> >
>> > This is a follow-up to my paper in Athlone and various emails since.
>> >
>> > Does this sound like a way to satisfy some users?
>> >
>> > In Csound5 pre-release phase we had a Csound for which nearly all
>> > opcodes were plugins in libraries based on the source file structure.
>> > At the time too many smaller devices could not deal with loadable code
>> > so this approach was abandoned in favour of the current schemes in
>> > cs6.
>> >
>> > We could redo this, and then the size/scope of a Csound would be
>> > selectable.  It might need some better way of selecting which
>> > components are to be loaded but that can wait.
>> >
>> > One could arrange the sources to it compiled either the current scheme
>> > or the total-plugin idea. Fundamentally it would be two building
>> > systems.  Certainly would be less disturbing than Minimal7. I am not
>> > sure how long this would take to do but it feels straightforward.
>> >
>> > It could be the basis of all Csound7 or be a sub-case.
>> >
>> > Any thoughts or comments?
>> >
>> > ==John ffitch

> I simply don't agree with you about the WASM build. I don't think this matters. It might take a bit longer to load but it will run just fine.

Download size matters because it has a direct impact on SEO and bounce rate.

I'm happy with its current size and agree that the added pressures and
complexity are not a good enough tradeoff right now. Would I use a
smaller Csound WASM if it was available, though? Absolutely!



On Thu, Dec 22, 2022 at 10:52 AM Michael Gogins
<michael.gogins@gmail.com> wrote:
>
> I simply don't agree with you about the WASM build. I don't think this matters. It might take a bit longer to load but it will run just fine.
>
> About the embedded systems, you have a point, but only if you have a pretty small embedded system. Still, you have a point.
>
> The pressures this feature would add for me are complexity causing additional and, in my opinion, unneeded and distracting maintenance.
>
> Perhaps the sizes of things would be smaller if the compiler optimized for size instead of speed? Or for a balance of size and speed? With -O3, the compiler does a LOT of inlining and some loop unrolling, and both definitely make the executable code bigger. I suggest using the -Os option, this does all optimizations that -O2 does, except for optimizations that increase code size. Last time I checked, -O2 was not far from -O3 in execution speed. so -Os might be a good tradeoff.
>
> Regards,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Wed, Dec 21, 2022 at 10:19 PM andy fillebrown <andy.fillebrown@gmail.com> wrote:
>>
>> 4Mbs is a lot on some embedded systems, and for the WASM build I would
>> love to make the Csound download smaller. Hlodver has done really good
>> work getting the size down, but it could be even smaller if there was
>> a way to easily remove the unused bits. Every byte counts when it
>> comes to web pages.
>>
>> Perhaps there is some middle ground? I'm not a front-end developer, so
>> forgive my ignorance in asking, but what pressures would this feature
>> add on you?
>>
>> On Tue, Dec 20, 2022 at 2:38 PM Rory Walsh <rorywalsh@ear.ie> wrote:
>> >
>> > Personally I would not like to see these opcodes become plugins. The current csound64 library contains pretty much all you need to build outstanding audio software. As a single library it's fantastic. I don't understand why we would choose to remove some of that functionality and place it into different plugin libraries and add further pressure on frontend developers. What is to be gained from this? In my view it makes using csound as a library far less attractive.
>> >
>> > csound64.dll is currently 4Mbs on Windows. How much smaller does it need to be?
>> >
>> >
>> >
>> > On Tue, 20 Dec 2022 at 18:09, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>> >>
>> >> I think a first step could be to make all opcodes in /Opcodes plugins, keeping /OOps internal and see where that gets us.
>> >>
>> >> Prof. Victor Lazzarini
>> >> Maynooth University
>> >> Ireland
>> >>
>> >> > On 20 Dec 2022, at 17:07, John <jpff@codemist.co.uk> wrote:
>> >> >
>> >> > *Warning*
>> >> >
>> >> > This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> >> >
>> >> > This is a follow-up to my paper in Athlone and various emails since.
>> >> >
>> >> > Does this sound like a way to satisfy some users?
>> >> >
>> >> > In Csound5 pre-release phase we had a Csound for which nearly all
>> >> > opcodes were plugins in libraries based on the source file structure.
>> >> > At the time too many smaller devices could not deal with loadable code
>> >> > so this approach was abandoned in favour of the current schemes in
>> >> > cs6.
>> >> >
>> >> > We could redo this, and then the size/scope of a Csound would be
>> >> > selectable.  It might need some better way of selecting which
>> >> > components are to be loaded but that can wait.
>> >> >
>> >> > One could arrange the sources to it compiled either the current scheme
>> >> > or the total-plugin idea. Fundamentally it would be two building
>> >> > systems.  Certainly would be less disturbing than Minimal7. I am not
>> >> > sure how long this would take to do but it feels straightforward.
>> >> >
>> >> > It could be the basis of all Csound7 or be a sub-case.
>> >> >
>> >> > Any thoughts or comments?
>> >> >
>> >> > ==John ffitch

Hi Andy. For me it comes down to a few things, more moving parts is more maintenance. Windows has always been dll hell. Adding another couple of hundred to the mix is going to add further pressure to Stephen who has done a remarkable job of packing the windows builds over the last few years. Another concern for me is the recent trend I'm seeing in hosts blacklisting plugins that try to load additional libraries on startup. Right now some hosts won't run any plugins unless Csound is statically linked to the plugin lib itself. Other hosts sandbox everything, making it even more awkward to distribute lots of additional libs. 

I think the best middle ground here would be for extended CMake build options to allow users more control over what goes into a build, but I think the current inclusion of /Opcodes should be the default for desktop platforms. I'd be interested to see how much of a difference removing these internal opcodes would have on the overall size of Csound. 

On Thu, 22 Dec 2022 at 03:19, andy fillebrown <andy.fillebrown@gmail.com> wrote:

4Mbs is a lot on some embedded systems, and for the WASM build I would
love to make the Csound download smaller. Hlodver has done really good
work getting the size down, but it could be even smaller if there was
a way to easily remove the unused bits. Every byte counts when it
comes to web pages.

Perhaps there is some middle ground? I'm not a front-end developer, so
forgive my ignorance in asking, but what pressures would this feature
add on you?

On Tue, Dec 20, 2022 at 2:38 PM Rory Walsh <rorywalsh@ear.ie> wrote:
>
> Personally I would not like to see these opcodes become plugins. The current csound64 library contains pretty much all you need to build outstanding audio software. As a single library it's fantastic. I don't understand why we would choose to remove some of that functionality and place it into different plugin libraries and add further pressure on frontend developers. What is to be gained from this? In my view it makes using csound as a library far less attractive.
>
> csound64.dll is currently 4Mbs on Windows. How much smaller does it need to be?
>
>
>
> On Tue, 20 Dec 2022 at 18:09, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>
>> I think a first step could be to make all opcodes in /Opcodes plugins, keeping /OOps internal and see where that gets us.
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>> > On 20 Dec 2022, at 17:07, John <jpff@codemist.co.uk> wrote:
>> >
>> > *Warning*
>> >
>> > This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> >
>> > This is a follow-up to my paper in Athlone and various emails since.
>> >
>> > Does this sound like a way to satisfy some users?
>> >
>> > In Csound5 pre-release phase we had a Csound for which nearly all
>> > opcodes were plugins in libraries based on the source file structure.
>> > At the time too many smaller devices could not deal with loadable code
>> > so this approach was abandoned in favour of the current schemes in
>> > cs6.
>> >
>> > We could redo this, and then the size/scope of a Csound would be
>> > selectable.  It might need some better way of selecting which
>> > components are to be loaded but that can wait.
>> >
>> > One could arrange the sources to it compiled either the current scheme
>> > or the total-plugin idea. Fundamentally it would be two building
>> > systems.  Certainly would be less disturbing than Minimal7. I am not
>> > sure how long this would take to do but it feels straightforward.
>> >
>> > It could be the basis of all Csound7 or be a sub-case.
>> >
>> > Any thoughts or comments?
>> >
>> > ==John ffitch