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

all sounds great.  so much clearer.

*- Dr.B*


*Dr. Richard Boulanger*

Professor

Electronic Production and Design

*Berklee College of Music*

Professional Writing & Technology Division


On Sun, Jul 7, 2024 at 7:01 PM 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
>