Submodule and Directory Structure

[ryukau]

I'm planning to add submodules (DPF and possibly VST 3 SDK) to this repository. And this is good time to discuss about directry structure.

I start from directory structure. Submodule placement will be discussed after we decide directory structure.

Current master puts everything on top level directory. I'm currently using following structure in gui branch:

.
├── faust
│   └── # Current top level files in `master`.
├── plugin
│   └── # C++ things.
├── README.md
# Other files.

Advantage of this structure is we can split Faust related build script from top level build script. Build script here means Makefile, CMakeLists.txt, or somthing like install.py.

Your thoughts?

[magnetophon]

Sure, I can do that.

Where do you want the qjackctl patchbay defenition? I use it for testing. When you load it into qjackctl, it automatically connects everything when I re-run DigiDrie.

[ryukau]

faust/various/DigiDrie.xml is good to me.

Just in case, gui branch has the described directory structure. Below is how it look like in gui.

.
├── faust
│   ├── benchmark
│   │   └── # Codes for `faustbench`.
│   ├── DigiDiagram.dsp
│   ├── DigiDrie.dsp
│   ├── DigiFaustMidi.dsp
│   ├── doc
│   │   └── # Some documenation related to Faust.
│   ├── lib
│   │   ├── DigiDrie.lib
│   │   ├── GUI.lib
│   │   └── lastNote.lib
│   ├── various
│   │   └── DigiDrie.xml
│   └── .gitignore # Top level .gitignore from `master`.
├── plugin
│   └── # ...
├── LICENSE.txt
└── README.md

---

I'm thinking about 2 different submodule (or external libraries) placement.

1. Place all submodule to submodule directory at top level.
2. Place submodule case by case to relevant directory.

1 is much more tidy. 1 also removes potential dupliction of submodule.

2 is convenient to me. Because in this case, I can just copy & paste my existing code to this repository. So the advantage is speed up of development.

What do you think?

[magnetophon]

My own code is extremely untidy: Lot's of dead code, lot's of commented out code and very little thought on function names and locations or file names and location.

There are 3 reasons for that:

• Speed of development
• The project is small enough to not get lost in the code. I navigate mostly with:
  • "Jump to definition" shortcut of doom emacs, my editor of choice.
  • "Search word in file" shortcut. In vim and doom that's *.
  • "Search word in project" shortcut
• Lazynes.

So it would be silly if I told you to use 1. Do what works best for you. As I don't speak C++ very well, I'm unlikely to ever look at your code a lot.

There might be other contributors in the future, but I wouldn't let it influence your decision too much.

As for the submodule and directory structure in master: I suggest that you rename gui to master as soon as it works better or the same as master. Of course let me know when you are ready to do this, so I can test it and make sure I don't have unpushed changes.

[ryukau]

OK, then I'll go with option 2 here. My concern was on duplication of C++ libraries, but it sounds like not to happen anytime soon.

gui branch is ready to merge. Let me know when you are ready.

Off topic: I was growing emacs config to replace VS Code at some point. But after upgraded to latest package from Fedora repo, my config starts crashing as soon as I open dired. Someone said growing emacs config is like taking care of bonsai. I feel it now.

[magnetophon]

gui branch is ready to merge. Let me know when you are ready.

That is very exciting to hear! I just removed some un-needed groups, I hope that doesn't cause you too much work!

I'm ready for the merge! :)

growing emacs config is like taking care of bonsai.

That is why I use doom: 338 people are cutting and watering my little tree!

But after upgraded to latest package from Fedora repo, my config starts crashing.

That is why I use NixOS: You can allways roll back, and you (can) have your whole config under git.

[ryukau]

Merged gui to master. If something is going wrong, please let me know.

[magnetophon]

Can I build this? How?

[ryukau]

I'll add build script later. Currently, only C++ code generator is on this repo.

[magnetophon]

Should I take care of anything when I change the faust code?

What can I do without causing you a lot of work?

Can I just add parameters?

Can I re-arrange parameters? For example: I'm thinking of re-writing the faust gui to have almost the same structure as your gui; so all the params of one macro on one page. I'm guessing that would break your code, right?

[ryukau]

In general, changing UI hierarchy breaks the C++ code generator. Adding or removing items to existing group is not a problem. To get better idea about UI hierarchy, you can run following command and take a look at DigiFaustMidi.dsp.json.

faust -t 0 -time -json DigiFaustMidi.dsp

Should I take care of anything when I change the faust code?

What can I do without causing you a lot of work?

For now, I'm OK to track your change on Faust code. But once the feature is stabilized, please do not change the hierarchy of *group primitives.

Can I just add parameters?

Yes.

Can I re-arrange parameters?

If parameter only moves inside of same group, like changing the order, it will not likely break the code. Adding more groups may add some work.

For example: I'm thinking of re-writing the faust gui to have almost the same structure as your gui; so all the params of one macro on one page. I'm guessing that would break your code, right?

Yes. This certainly breaks the code, but I'm OK for it. Restructure of groups may make C++ generator code much simpler.

[ryukau]

I pushed plugin related files to master. Build instruction is added to readme (link). I'll add more proper build script later.

[magnetophon]

I don't feel comfortable breaking your code, so I'll be pushing to the faust branch from now on.