App Design Question (Juce Newbie)

Hi Everyone,

I am new to Juce and would like suggestions for my Project’s design using Juce.

I am a music educator, have been programming for many years, mainly within the Mac Universe (Hypertalk, Carbon, Cocoa). I am comfortable with C++ and Objective-C and have written code for synthesis, MIDI routing, algorithmic composition, …

I’ve been working on the Juce tutorials to get familiar with the framework and now I decided to start an application project. I chose Juce mainly because of its audio and multiplatform support. My Aplication is a collection of exercises for ear training for use in class (and eventually, if I manage to do a decent job, perhaps distributing for Mac/Windows/Linux).

After trying some of the demos, I thought of using a single window and loading each lesson as predefined component over an area within the main component. Figured that, since each “page” would use a different combination of buttons, sliders, etc, I could swap pages just by adding and removing child components. The only thing is that I would end up with a ton of files with component-derived classes, one for each “page”. Another possibility I considered would be to use one giant switch on the main component directing to a different method with GUI structuring code for each page. It seems that either solution would quickly escalate in complexity, especially since there will certainly be many pages of exercises (perhaps dozens of them).

I would appreciate any comments and/or suggestions for other strategies. I am just trying to start out in the right track and avoid having to redo everything once I get the app going.
Thanks in advance and please forgive me for the length of the message (promise I’ll keep them shorter in the future).

Musically,

Carlos E. Mello
University of Brasília, Brazil

It sounds like you try to do exactly what the DemoRunner does. If you look at the git repository next to the Projucer, did you build and run the DemoRunner?
And it could serve as inspiration for your project as well.

I see what you mean. I played with the Demo Runner a little, as it came with my Juce installation, Just didn’t realize the source was available. Will look into that. Thanks for the tip.

Very interesting question! I’m myself interested in how devs organize and design their components. I’ve never felt like having a large hierarchy - consequently a large number of source files and classes - would be a problem. The giant switch approach would be a total nightmare for me. I’d prefer organizing stuff into separate classes and components as far as possible and avoiding redundancy by designing the components as flexible and reusable as possible.

I wouldn’t take the demo runner as a good reference. The demo runner packs a lot of stuff - basically whole apps - into single source files, which may make sense in the demo runner, but i would never do something like that in the projects i work on.

Of course in your case, if the “pages” can be described with - say XML - i would consider a component that would present what’s in the XML. Of course you might then have to think about whether you even need JUCE components in your UI or could you just use some kind of web UI.

Anyway, in the cases where i’ve needed a large number of “views”, which are by most parts quite similar to each other, using some kind of higher level description representing only the information unique to each page the as the basis for the UI has worked well for me.

1 Like

Hi, I managed to streamline the interface and reduced the number of page classes to 12. They all inherit from a base Page class which communicates with the main component through ActionBroadcaster messages.The pages are swapped in place by the main component’s menu buttons and displayed one at a time into a display area. I use just one pointer to a Page object and allocate/deallocate as needed. Now I will develop one page class at a time so I can test incrementally. Nothing fancy, but now I have a plan.

Thanks everyone for the comments and suggestions.

i’d indeed make pages. it is tedious to manually replace sub components after you add more than 2 pages