JUCE Examples?

[slajar]

Dear all,

I am currently evaluating JUCE and the library is great! Unfortunately there is a lack of documentation. That's why I decided to wrap my knowledge directly into sample code. I sent the first one to Julian and he wasn't really enthusastic about my way of implementing this sample

One major difference is that I am not using JUCE as a UI library but I really like the whole architecture and espacially the Audio-Part. That's why I build a command line tool witch runs a very small Audio-Graph. For me it is the smallest piece of code I can write to run a custom build DSP on a Microphone input + Default Soundcard Output.


Now my question. What do you think? Should I rewrite the Code to use JuceUI or should I leave it like that and we have a somewhat tweaked command line example?


For my personal use I will definetely go forward using the Non-UI code

kind regards
Matthias

[slajar]

Is there really no need for further sample code?

[Daven]

No, you're probably not looking in the right places.

There's more than adequate documentation of juce, google "juce api"


It's not clear what you're talking about regarding sample code.

"I sent the first one to Julian and he wasn't really enthusastic about my way of implementing this sample" -- what are you talking about?

I mean no offense, but you might have more luck if you got someone to help proofread these messages, assuming English is a second language.

[dave96]

For my personal use I will definetely go forward using the Non-UI code

If you are developing a command line app, there is no point in building a UI just to post code here as it will just overcomplicate the issue. Sometimes interface elements are useful/necessary when developing and testing for the visual representation of audio but that will depend on your use case.

As Daven said there is a wealth of documentation built into the Juce library code itself. This is in Doxygen format and a html version can be found here.

For example code the best resources are the Juce Demo and Audio Host programs located under "extras". Otherwise there is the Juce wiki and the Useful Tools and Components forum for user provided examples.

[Werner]

Hi slajar,

I'd like to see more examples, but please with GUI.

[jrlanglois]

Should I rewrite the Code to use JuceUI or should I leave it like that and we have a somewhat tweaked command line example?

I don't understand how that's any easier than using the Jucer to do an example with an interface, and slap on functionality on top when satisfied with your GUI.

Moreover, wouldn't doing a GUI make it easier for people to understand an example? Not everybody understands what code does when they see just code - so if the aim is creating an easy to grasp example, definitely go with a GUI.

[slajar]

Thanks everyone!

No, you're probably not looking in the right places.
There's more than adequate documentation of juce, google "juce api"

You don't talk about a doxygen generated documentation, do you? From my point of view this is not a real appropriate documentation.
It's a real good thing if you already understood how things work and you just need some hints. I case you're a noob you'll probably need
to get a good understanding about the main concepts (I've seen there is a real good tutorial for building UIs but nothing equally for the audio stuff).
IMHO, using doxygen is the open source way to save time and it is not a good way for the usability of an API.
I am expecting sample codes for each task and a good developer documentation for all APIs we are using.

Since I wanted to help I started to write samples.

It's not clear what you're talking about regarding sample code.
"I sent the first one to Julian and he wasn't really enthusastic about my way of implementing this sample" -- what are you talking about?

I am not sure why this is not clear. I sent a zipped package with my proposed sample code to Julian and he dind't like the way I used JUCE.

I mean no offense, but you might have more luck if you got someone to help proofread these messages, assuming English is a second language.

Yes, english is not my first language but I don't think that matters if you're not picky

If you are developing a command line app, there is no point in building a UI just to post code here as it will just overcomplicate the issue. Sometimes interface elements are useful/necessary when developing and testing for the visual representation of audio but that will depend on your use case.

Yes, they are neccesarry sometimes. My question was, could we have a sample code without UI or is this just senseless since JUCE is always about UI?

Btw, I didn't say that I am building a command line tool, we are just not using JUCE as a UI platform. Therefore the implementation of the backend is quite similar to a command line tool.

As Daven said there is a wealth of documentation built into the Juce library code itself. This is in Doxygen format and a html version can be found here.

Hhm, As I said above I don't see a doxygen generated HTML files as a real documentation. I am expecting much more especially for noobs. Currently, I think it's way to hard to get first simple things done. I don't say the API isn't great It is great and you can do so much with it. Since it's complex even tiny examples grow pretty fast. So I think the smaller an example is the better it is for beginners.

For example code the best resources are the Juce Demo and Audio Host programs located under "extras". Otherwise there is the Juce wiki and the Useful Tools and Components forum for user provided examples.

Sure this is really nice but I was expecting striped down examples. That's why I decided to write some and contribute them to the project.

I'd like to see more examples, but please with GUI.

Ok, I see. Our approach is probably too far away from what "normal" Juce-users do. I am going to adapt the sample codes and submit them afterwards

[jules]

My question was, could we have a sample code without UI or is this just senseless since JUCE is always about UI?

If you only use classes that don't require an event loop to be running, then of course you can write a non-UI app with a main() function, etc.

But what you were trying to do was to use a bunch of UI-based classes without actually providing an event loop to service them, so they're not going to stand much chance of working correctly. And the only sensible way to provide an event loop is just to build a normal GUI app, even if you don't intend to make it open any windows.

[jules]

BTW: a quick way to find out whether you need an event loop or not is just to look at whether your app requires the juce_events module. If it does, then you need an event loop. If you don't use any modules that depend on juce_events, then you're fine with a normal main() function.

[slajar]

My question was, could we have a sample code without UI or is this just senseless since JUCE is always about UI?

If you only use classes that don't require an event loop to be running, then of course you can write a non-UI app with a main() function, etc.

But what you were trying to do was to use a bunch of UI-based classes without actually providing an event loop to service them, so they're not going to stand much chance of working correctly. And the only sensible way to provide an event loop is just to build a normal GUI app, even if you don't intend to make it open any windows.

Thank you for your answer.

From my point of view I was not using any UI specific classes. The goal was to have audio input and audio output and a very small DSP chain. There is nothing UI specific. I' am going to track down which module includes juce_events maybe I can eliminate it.

[jules]

There is nothing UI specific.

It's not just visual components that require an event loop. Anything that uses async messages needs one.

[slajar]

Thanks.
I just found that even the AudioProcessor module needs juce_gui_base and juce_gui_extra modules. That means it is not possible to build such an headless audio example.
So, I am going to change the sample code.

[bpartridge]

FWIW I've been working on a headless program using AudioProcessors, and I can confirm that VST loading, instance->processBlock, and AudioFormatWriters work without needing an event loop (at least on OS X). You just need to create the plugin instances on the main thread (the one running your main() function), and you can use the others from worker threads. The async stuff doesn't come into play unless you instantiate the plugin editor interfaces.