Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] Source tree reorganization

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 <[email protected]> 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
>> <[email protected]> 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 <[email protected]> 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