I just had an idea for a Projucer feature. I’m currently refactoring a bunch of files. My workflow usually goes like this: I create a new group and the h/cpp files i am going to need and then 1-by-1 start to rewrite what I already wrote, but with little improvements everywhere, so that the end result has mostly the same functionality but a better coding style, enabling me to work better on the upcoming features or bugs. But in C++ you can’t have 2 same namespaces with the exact same classes in 1 project, so I always give the new namespace the same name with an added number, like
namespace bandpass2
which means I also have to change all the places where I use the corresponding objects in the processor and editor to the new namespace. Also I get a lot of warnings because of duplicated file names, even if they are in different folders/groups. A solution to that is to remove the old files from the project. The Projucer nicely asks you if you wanna delete references only or wipe it off the harddrive completely. But I think it could go a step further and instead of deleting the references, just disabling them. That would result in esentially completely the same thing as removing the references in the IDE, but it would only grey out the files in the Projucer, making it easier to remember later you still had some files there you could come back to if your refactor doesn’t turn out to work, or just to remember you still need to remove them after the refactor was done.
the disabled files would just not be part of the c++ project anymore, just like if you deleted them or their references, but you could still look at the old code in the projucer’s code window, which would have a nice workflow for rewriting the files in a better way. you could have the projucer on one screen and the IDE on the other screen and then decide which things to keep and which things to write completely differently.
edit: this feature would also be useful for keeping track of outtakes. like you wrote some dsp code and encounter a bug that actually sounds kinda cool and you wanna keep the code but still fix the bug for now. atm i have to copy the code into a file outside of the project but it would be better if at least in the Projucer it would still be available and remind me of its existence, because otherwise it will most likely be forgotten soon.
I envisioned it as the names of disabled files being greyed out in the list, but it would indeed be more consistent with the other compile-features to be another column, yes
custom templates is literally my most wanted projucer feature! no more copying a project file and remembering which settings to change to make it a unique plugin (plugin ID and stuff).
The JUCE team better team up with your team and make it happen for everyone
I’m AFK at the moment but I believe you can already mark a file as “not compiled” in the Projucer. Clicking a folder in the sidebar shows you properties you can set on each file in the folder.
Disable “Compile” in this view.
Would that have the same effect as what you’re suggesting?
I believe he also wants the non-compiled files to be greyed out in the Projucer.
I think an extension of what he wants would be some sort of compiler group selector to switch between different variations of compiled file groups.
it’s not the same, because the header files are still part of the project and includable in the IDE, so you can’t go ahead and rewrite them with the same namespace and class names in a new file.
greying out stuff is just UI semantics. i’d be fine if it was another feature of that list thingie, like you suggested
I don’t understand the workflow. Do you want both sets of files to build in the same project, or do you just want to build the new files while referring to the old ones? If the latter, I’d normally approach this by using a Git client like Fork, Sublime Merge, or Clion to display the state of the repo pre-refactor. This way you can easily see the old state while making any changes you like to the current state.
The workflow idea in abstraction is that there are various kinds of situations in which it would be useful do declare a bunch of files as not part of the project anymore for the IDE while still seeing them in the Projucer, and I called that “dis/enabling the files”.
One example of this being useful is for outtakes. Imagine you wrote a filter, and it breaks out in the most obscure way ever, but doesn’t crash. You wanna keep the code for a later sounddesign plugin release or something, but since it doesn’t solve the intended purpose of your current project you also wanna fix the bug. With the new Projucer feature you could just copy the files and then disable the old ones so that you can still be reminded of their existence later when you have finished this project.
Another usecase is for refactoring the code base. You could disable a bunch of files and then create new empty ones with the same names, rewriting that part of your code base from scratch while having the old files visible on your other monitor in the Projucer to remember certain details quickly.
I know that this is a bit similiar to going back and forth with Git branches, but I still think it’s a bit different, because with Git you can’t easily be in 2 branches at the same time, without quite a bit of setup. It would be a much better workflow as a Projucer feature
Create branches for different features. Switch between them. Merge them when finished/fixed.
No need to rename files and namespaces. No need to see old files, etc.
Want to reuse a few classes but improve the code? Don’t make copies, put those files into a submodule, so you can upgrade your old projects by simply updating their submodules.
These are modern, standard development practices. Whatever you’re doing now is absolute chaos. You’re working like version control systems haven’t been invented yet.
I wouldn’t want a second of the JUCE team’s time wasted to accommodate these outdated, chaotic and error prone processes.
I think the right question to ask is whether the benefits in flow from @Mrugalla’s proposal outweigh the benefits of strong Git practices & modern IDE features.
I’ll play devil’s advocate. There are certainly scenarios (primarily creative) where individuals might prefer to work in a more chaotic environment until they’ve refined the code to the point where they’re ready to add it to version control.
Immediate, intuitive access might enhance rapid prototyping and experimentation for more novice users.
Would you use Git to manage all of your different takes in your DAW?
Being able to switch between several variants of node structure within an audio graph is inherently equivalent to being able to stack effects in your DAW on multiple tracks to do A/B/C comparisons.
It’s pretty easy for a non-programmer to use our engine to write compound effects in code. If they want to be able to keep track of every edit, and they may have around 15-20, it’s a bit odd to expect them to store all of those in a single file. It’s a bit more intuitive for them to create a new file and save it.
If this was about best practice, the Projucer wouldn’t exist in the first place.
It is exactly like QuilioLtd says. Software development has something chaotic to it when you’re still in the process of developing an algorithm and its code structure. You try various different strats until you find one that really suits the idea and refactoring the code a lot helps in not getting stuck with legacy code too early on in the project.
When it comes to the Projucer you all gotta consider that the reason why people are not amazed by it is probably not because it’s an inherintly bad idea to use a standalone application as a project organization tool. if it was a bad idea to do that big game engine’s would also have you write cmake files, but they don’t. they manage projects for you. the real reason why the Projucer doesn’t get a lot of love is because it hasn’t seen a cool new feature in ages, so people can barely imagine its potential for workflow improvements.
Also I’m still not convinced that the workflow I’m describing is worse than using Git branches. I mean, I was literally talking about the ability to see 2 different versions of the code side by side and when you have a git repository you can only be in 1 branch and commit at a time. You’d have to have the same repository open in 2 different folders to have it side by side. That’s a lot of stuff to do if you just wanna disable some files while rewriting them.
Also I wanna offer commiserations to everyone who believes audio programming does not have a creative component to it like music production. coming across weird sounding bugs can be a true joy and wish the ones who liked that comment to also experience it one day
You should be able to implement chaotic and creative workflows in many ways that are effective for you without asking the Juce maintainers to modify a part of Juce for that purpose. These guys have more important things to do.
Correct me if I’m wrong, but this is a open forum, and you’re certainly allowed to ask the JUCE maintainers for anything. It’s up to them to say no, or disregard and close the thread.
Topics also act as catalysts for discussion.
The JUCE team aren’t the only individuals reading through posts on the feature requests category.
