Hi All,

We've had a couple of conversations about this the past half year and
I thought I'd bring it up again. From my perspective we've been
essentially working with a monorepo made up of libraries and
applications, yet our code hasn't been as organized as it could be to
align with this. In particular, having the source for libcsound
intermixed at the same top-level as other folders doesn't really
encapsulate things well and makes it a little more difficult to find.

For a first iteration, I was thinking:

/libcsound - move H, include, Engine, Top, OOps (rename to opcodes), po

/plugins - InOut, Opcodes (break this up into one folder per plugin);
this folder could be broken up into different kinds of plugins
(opcodes, io, ftable, etc.)

/apps - all commandline apps that rely on libcsound. Move Frontends,
util, util1 (compiled commands). Also look at separating each
executable into their own folder. This adds a lot of folders but it
also makes it very clear for code relationships.

/util - move non-compiled code utilities here (util2, parts of util1)
as well as utility code that doesn't use libcsound (longline.c,
nsliders.tk).

/platform - platform-specfic code; use existing platform folder but
move Android, Bela, Daisy, iOS, Java (though this might be better
removed and separate repo for Java binding maintained), wasm, Python

Thoughts?

steven

I would prefer if we call the "plugins" directory as "modules", because they can be both built as plugins or built into the library.

Also there is code in InOut that is part of the library proper, so that should be moved elsewhere.

In libcsound, should we merge Top and Engine? Sometimes I feel that separation may not make much sense anymore.

Also given that many utils are modules as well, we should move these there.  The ones that are not modules can go elsewhere as you indicated.

Does it make sense to call the apps directory frontends (because that is what they are?)

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 5 Jul 2024, at 22:58, Steven Yi  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.
> 
> Hi All,
> 
> We've had a couple of conversations about this the past half year and
> I thought I'd bring it up again. From my perspective we've been
> essentially working with a monorepo made up of libraries and
> applications, yet our code hasn't been as organized as it could be to
> align with this. In particular, having the source for libcsound
> intermixed at the same top-level as other folders doesn't really
> encapsulate things well and makes it a little more difficult to find.
> 
> For a first iteration, I was thinking:
> 
> /libcsound - move H, include, Engine, Top, OOps (rename to opcodes), po
> 
> /plugins - InOut, Opcodes (break this up into one folder per plugin);
> this folder could be broken up into different kinds of plugins
> (opcodes, io, ftable, etc.)
> 
> /apps - all commandline apps that rely on libcsound. Move Frontends,
> util, util1 (compiled commands). Also look at separating each
> executable into their own folder. This adds a lot of folders but it
> also makes it very clear for code relationships.
> 
> /util - move non-compiled code utilities here (util2, parts of util1)
> as well as utility code that doesn't use libcsound (longline.c,
> nsliders.tk).
> 
> /platform - platform-specfic code; use existing platform folder but
> move Android, Bela, Daisy, iOS, Java (though this might be better
> removed and separate repo for Java binding maintained), wasm, Python
> 
> Thoughts?
> 
> steven

"modules" makes sense to me, as does merging Top and Engine. I like
and prefer "apps" as I think it's a little more common a terminology
than "frontends", but it's not a huge deal to me either way.

If we're good for this general direction, let's figure out a schedule
soon. (Perhaps we can get the feature/formatting branch up to date
with develop and get that integrated soon? I have to update the
feature/pass-by-ref branch with the latest from develop as well as
investigate expression parsing.)

On Sat, Jul 6, 2024 at 4:28 AM Victor Lazzarini
<000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:
>
> I would prefer if we call the "plugins" directory as "modules", because they can be both built as plugins or built into the library.
>
> Also there is code in InOut that is part of the library proper, so that should be moved elsewhere.
>
> In libcsound, should we merge Top and Engine? Sometimes I feel that separation may not make much sense anymore.
>
> Also given that many utils are modules as well, we should move these there.  The ones that are not modules can go elsewhere as you indicated.
>
> Does it make sense to call the apps directory frontends (because that is what they are?)
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 5 Jul 2024, at 22:58, Steven Yi  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.
> >
> > Hi All,
> >
> > We've had a couple of conversations about this the past half year and
> > I thought I'd bring it up again. From my perspective we've been
> > essentially working with a monorepo made up of libraries and
> > applications, yet our code hasn't been as organized as it could be to
> > align with this. In particular, having the source for libcsound
> > intermixed at the same top-level as other folders doesn't really
> > encapsulate things well and makes it a little more difficult to find.
> >
> > For a first iteration, I was thinking:
> >
> > /libcsound - move H, include, Engine, Top, OOps (rename to opcodes), po
> >
> > /plugins - InOut, Opcodes (break this up into one folder per plugin);
> > this folder could be broken up into different kinds of plugins
> > (opcodes, io, ftable, etc.)
> >
> > /apps - all commandline apps that rely on libcsound. Move Frontends,
> > util, util1 (compiled commands). Also look at separating each
> > executable into their own folder. This adds a lot of folders but it
> > also makes it very clear for code relationships.
> >
> > /util - move non-compiled code utilities here (util2, parts of util1)
> > as well as utility code that doesn't use libcsound (longline.c,
> > nsliders.tk).
> >
> > /platform - platform-specfic code; use existing platform folder but
> > move Android, Bela, Daisy, iOS, Java (though this might be better
> > removed and separate repo for Java binding maintained), wasm, Python
> >
> > Thoughts?
> >
> > steven

It may be better to cherry pick the commit relating to the formatting scripts rather than trying to merge or rebase that branch. We can try either route.

My plan is to continue working on the host API branch to complete that proposal. I've only been doing some debug fixes, I have not put much mind to that yet.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 8 Jul 2024, at 00:01, Steven Yi  wrote:
> 
> "modules" makes sense to me, as does merging Top and Engine. I like
> and prefer "apps" as I think it's a little more common a terminology
> than "frontends", but it's not a huge deal to me either way.
> 
> If we're good for this general direction, let's figure out a schedule
> soon. (Perhaps we can get the feature/formatting branch up to date
> with develop and get that integrated soon? I have to update the
> feature/pass-by-ref branch with the latest from develop as well as
> investigate expression parsing.)
> 
>> On Sat, Jul 6, 2024 at 4:28 AM Victor Lazzarini
>> <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:
>> 
>> I would prefer if we call the "plugins" directory as "modules", because they can be both built as plugins or built into the library.
>> 
>> Also there is code in InOut that is part of the library proper, so that should be moved elsewhere.
>> 
>> In libcsound, should we merge Top and Engine? Sometimes I feel that separation may not make much sense anymore.
>> 
>> Also given that many utils are modules as well, we should move these there.  The ones that are not modules can go elsewhere as you indicated.
>> 
>> Does it make sense to call the apps directory frontends (because that is what they are?)
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>>> On 5 Jul 2024, at 22:58, Steven Yi  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.
>>> 
>>> Hi All,
>>> 
>>> We've had a couple of conversations about this the past half year and
>>> I thought I'd bring it up again. From my perspective we've been
>>> essentially working with a monorepo made up of libraries and
>>> applications, yet our code hasn't been as organized as it could be to
>>> align with this. In particular, having the source for libcsound
>>> intermixed at the same top-level as other folders doesn't really
>>> encapsulate things well and makes it a little more difficult to find.
>>> 
>>> For a first iteration, I was thinking:
>>> 
>>> /libcsound - move H, include, Engine, Top, OOps (rename to opcodes), po
>>> 
>>> /plugins - InOut, Opcodes (break this up into one folder per plugin);
>>> this folder could be broken up into different kinds of plugins
>>> (opcodes, io, ftable, etc.)
>>> 
>>> /apps - all commandline apps that rely on libcsound. Move Frontends,
>>> util, util1 (compiled commands). Also look at separating each
>>> executable into their own folder. This adds a lot of folders but it
>>> also makes it very clear for code relationships.
>>> 
>>> /util - move non-compiled code utilities here (util2, parts of util1)
>>> as well as utility code that doesn't use libcsound (longline.c,
>>> nsliders.tk).
>>> 
>>> /platform - platform-specfic code; use existing platform folder but
>>> move Android, Bela, Daisy, iOS, Java (though this might be better
>>> removed and separate repo for Java binding maintained), wasm, Python
>>> 
>>> Thoughts?
>>> 
>>> steven

Sounds good on formatting.

FYI: I'm also working on a new Java binding to Csound using Java's new
FFM (foreign function and memory) API that was released in Java 22.
This works like ctypes in Python where all of the work to load
libraries, lookup symbols, and deal with native memory is done in Java
code, so no native library component required (as we had with SWIG and
CsoundJNI). I have the start of this pushed to:

https://github.com/kunstmusik/CsoundFFM

Going to target Csound6 API first, migrate to it for Blue to test it
out, then look at Csound7 support.


On Mon, Jul 8, 2024 at 3:54 AM vlz  wrote:
>
> It may be better to cherry pick the commit relating to the formatting scripts rather than trying to merge or rebase that branch. We can try either route.
>
> My plan is to continue working on the host API branch to complete that proposal. I've only been doing some debug fixes, I have not put much mind to that yet.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 8 Jul 2024, at 00:01, Steven Yi  wrote:
> >
> > "modules" makes sense to me, as does merging Top and Engine. I like
> > and prefer "apps" as I think it's a little more common a terminology
> > than "frontends", but it's not a huge deal to me either way.
> >
> > If we're good for this general direction, let's figure out a schedule
> > soon. (Perhaps we can get the feature/formatting branch up to date
> > with develop and get that integrated soon? I have to update the
> > feature/pass-by-ref branch with the latest from develop as well as
> > investigate expression parsing.)
> >
> >> On Sat, Jul 6, 2024 at 4:28 AM Victor Lazzarini
> >> <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:
> >>
> >> I would prefer if we call the "plugins" directory as "modules", because they can be both built as plugins or built into the library.
> >>
> >> Also there is code in InOut that is part of the library proper, so that should be moved elsewhere.
> >>
> >> In libcsound, should we merge Top and Engine? Sometimes I feel that separation may not make much sense anymore.
> >>
> >> Also given that many utils are modules as well, we should move these there.  The ones that are not modules can go elsewhere as you indicated.
> >>
> >> Does it make sense to call the apps directory frontends (because that is what they are?)
> >>
> >> Prof. Victor Lazzarini
> >> Maynooth University
> >> Ireland
> >>
> >>>> On 5 Jul 2024, at 22:58, Steven Yi  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.
> >>>
> >>> Hi All,
> >>>
> >>> We've had a couple of conversations about this the past half year and
> >>> I thought I'd bring it up again. From my perspective we've been
> >>> essentially working with a monorepo made up of libraries and
> >>> applications, yet our code hasn't been as organized as it could be to
> >>> align with this. In particular, having the source for libcsound
> >>> intermixed at the same top-level as other folders doesn't really
> >>> encapsulate things well and makes it a little more difficult to find.
> >>>
> >>> For a first iteration, I was thinking:
> >>>
> >>> /libcsound - move H, include, Engine, Top, OOps (rename to opcodes), po
> >>>
> >>> /plugins - InOut, Opcodes (break this up into one folder per plugin);
> >>> this folder could be broken up into different kinds of plugins
> >>> (opcodes, io, ftable, etc.)
> >>>
> >>> /apps - all commandline apps that rely on libcsound. Move Frontends,
> >>> util, util1 (compiled commands). Also look at separating each
> >>> executable into their own folder. This adds a lot of folders but it
> >>> also makes it very clear for code relationships.
> >>>
> >>> /util - move non-compiled code utilities here (util2, parts of util1)
> >>> as well as utility code that doesn't use libcsound (longline.c,
> >>> nsliders.tk).
> >>>
> >>> /platform - platform-specfic code; use existing platform folder but
> >>> move Android, Bela, Daisy, iOS, Java (though this might be better
> >>> removed and separate repo for Java binding maintained), wasm, Python
> >>>
> >>> Thoughts?
> >>>
> >>> steven