I’m new here. I haven’t really used JUCE although I researched many years ago when I saw MaxMSP was rebuilt in JUCE. I’m programmer, designer, musician, yadda yadda.
I’m applying for a small grant in order to develop either a prototype or MVP for a concept. There are many ways to approach a prototype. I can fake it. It can be barely functional. Maybe it’s a good idea to start building in JUCE. Maybe it’s a bad idea.
I’d love to get opinions on developing MVPs and prototypes in JUCE.
- What has your experience been when fleshing out your ideas?
- Is it a good to approach it this way or would you recommend other technologies for prototyping? (MaxMSP for example which I have a lot of experience with).
What am I developing (depending on the grant)?
A sort of experimental, lightweight, DAW focused exclusively on scoring.
You’re applying for a grant to build a prototype? I’m not the brightest spark in a welders shed but applying for financial aid when you haven’t got a prototype ready sounds risky.
- How do you know you can actually accomplish the goal?
- What happens if you can’t but you’re stuck paying back the money?
Also, would this financier not want to see an actual prototype first? They’re not just gonna give money to anybody, or they’d go bankrupt quickly.
It would be like going on Shark Tank and saying “I haven’t got anything with me, but I do have an idea”. How do we know this idea actually works? Or if you can even accomplish such a feat?
Not meant to be rude either, FYI, just worried that you might be backing yourself into a dangerous corner.
Aside from that, JUCE is perfect for both prototypes AND finished products. Since it is a DAW, before even dreaming about sending off an application, consider the following;
- build a basic piano roll
- build a basic project save and load function
- build a basic arranger/tracklist manager
- build a basic mixer
- build a basic plug-in loader
- build a basic Synth
If you can’t do all of those yet, don’t send an application just now. Work on building the very basic, in solo apps, FIRST. Then combine them all into a basic prototype.
Considering the fact that you are making a DAW for composers so-to-speak, I’m guessing the Hanz Zimmer type stuff, you’re going to need orchestral samples and sources ready to show the financier where you plan on spending their money.
Best way to start a prototype is to just start. It all depends on your personal style. Gather references like FL, Abelton, Studio One and choose ONLY the necessary elements, build them extremely basic, then move into the next. After you’re done with the basics, combine them all into a nice, neat project and ensure it works as intended.
there are a lot of DAWs out there already and they are strong and rich of features. make sure to have some features in mind that are so innovative that the other daw devs could barely find a way to copy them into their daws (like “the grid” in bitwig). also it must be a useful and huge feature ofc
My 2 cents, without knowing how big this project is:
- If you feel the itch to really do it and believe you have some perseverance, then do it: you’ll learn a lot and if it works out, you’ll have what you wanted, and if you checked with other people (see point 3) you’ll be able to get some monetary reward for your work too.
- Make sure you have a good idea about what the thing should do and how you would operate it before you start coding: make many sketches, think about how you start the product, the necessary actions, how you would go about doing that interaction-wise, and also what core functionality you’ll need behind the scenes to get that. This won’t (and probably can’t) be complete or detailed from the start, but you should do the “thinking this through” process at least once, and then expect that you’ll definitely need to fine-tune / revise along the way in a few iterations to get it right.
- Check your idea and first thoughts with a few trustworthy people. Listen to them and be open for the feedback. But also don’t necessarily accept every piece of “you should do it this way” advice: you can’t please everyone in every detail, but if you see a common thing come back a few times, there may be something to it. Also: several innovative products wouldn’t exist if the people who made them had listened to the “nah, that won’t work” or “no, you should do it this way”. It’s up to you to check if the advice you get is indeed valid, or not. Since this is only for a prototype at this point, you can still try a few different things.
- This is in the understanding that it’s indeed a grant you’re talking about: funding that does not need to be paid back (so it’s not a loan), but the funder of course does expect your “best efforts” to work towards that prototype. If it is a loan, and it’s the first product you’re building yourself, be very very careful, and maybe try to get to a very basic MVP in another way first…
As for prototyping in Max/MSP:
I never did that, but if you think Max/MSP could do the things you’ll need, then that might indeed be a first good step for the general outline. I probably would avoid spending too much time in going into all the details if you’ll need it to be done in JUCE/C++ afterwards anyway.
As said above: this is advice from 1 person. It’s up to you to decide if you find it useful or not