Streamlining the demo experience


#1

It seems the mac demo plugin project is set up to build only on 10.6 without issue, and assumes RTAS files exist. I got the git tip today on 10.5, and had to change the Core Audio file paths, set header paths, and remove the RTAS dependencies. The RTAS stuff seems kind of silly since I’m sure very few newbs are able to deploy in this format and probably don’t possess the files anyway. Adding RTAS support, rather than removing it, should be the extra step IMHO. Other than those issues, which are not obvious to solve, the resulting plug-in works as expected. I’m not if there is a clean way to set up the demo project to build seamlessly “out of the box” on 10.5 and 10.6, but it would be nice…


#2

I do agree, but can’t really think of much I can do about those things… I tried to put as much detail as possible in the readme file.

Explaining how to add the RTAS files would be much harder than explaining how to get rid of them, which is why I left them in there. I suppose I could have two projects, one without RTAS, but it’d be a faff to keep them in sync. I’ve tried to find a cunning way to only link to the RTAS library when it’s enabled, but for some reason couldn’t get the -l linker flag to do its job properly…


#3

[quote=“jules”]I do agree, but can’t really think of much I can do about those things… I tried to put as much detail as possible in the readme file.
[/quote]

How about a separate OS 10.5 project? I have spent quite a bit of time today trying to set up the new paths, but am still getting errors (edit: I fixed these). The RTAS stuff doesn’t bug me as much, but having to change everything around to get a demo project to work is pretty annoying.

Plus, how many RTAS developers are working in OS 10.6 anyway? The publicly available Pro Tools builds don’t run in 10.6.

Having two separate projects, one 10.6 and one 10.5, seems like it would be much more useful for people who want to try out Juce, but aren’t on the bleeding edge of the operating system.

So…please? Pretty please, with sugar on top?

Sean Costello


#4

Then how come I’m happily building RTAS stuff in 10.6 (?)

But is it really such a big deal? If you make a copy of the CoreAudio files in your developer folder with the new “correct” file location, then either version of the project will build with no problems, and you’ll never need to touch them again. I really don’t fancy keeping multiple versions of the project up-to-date.


#5

Then how come I’m happily building RTAS stuff in 10.6 (?)
[/quote]

Building is one thing. Running it is another. Many of the audio applications out there aren’t running that well in 10.6 yet. I’m more interested in having an environment that allows me to test my plugin in the majority of the hosts people might be using, than staying on the leading edge.

[quote]
But is it really such a big deal? If you make a copy of the CoreAudio files in your developer folder with the new “correct” file location, then either version of the project will build with no problems, and you’ll never need to touch them again. I really don’t fancy keeping multiple versions of the project up-to-date.[/quote]

I’ve made a copy of the CoreAudio files. But it was a pain. And newbie users, who download Juce, try to compile it, and get 90-some errors, might decide to move on, instead of figure out why the example doesn’t compile. Plus, if you keep 2 projects up to date, you have 1 pain in the ass unit (PIAU) for every time you have to change the project. If you just have the 10.6 project, you have X number of users that have to go through the process, which is X*PIAU.

Sean Costello


#6

Maybe we should just ask apple to move the files back… :expressionless:


#7

Yeah, you drive down there and get on that. :slight_smile:

It might be a good idea to set up a directory structure, or alias, that mirrors the new Apple file locations. Can anyone describe where these should be located?

Thanks,

Sean Costello


#8

Hello,

I’m using 10.6 for building and testing RTAS plugins.

Other than that, I guess a simple script could be written to copy the concerned apple files in their previous location ?
Or to change the path of the files in the xcode project ?

I already use such script to automatically fix the path of the 3 digi files (xcconfig files & plugin lib) that are expecting jules’s computer.

Finally, I think that in addition to the valuable ‘How to use this framework’, a thread dedicated to plugin common compiling /linking error , with solutions, would help.

If some interest in that, I can share my own little list.

Salvator


#9

Me too. Amazingly, even PT7.4 runs quite happily.

I’m updating the how-to-build file with a detailed explanation of the CoreAudio folder move.

Good idea, I’ll start one.


#10

[quote=“jules”]I’m updating the how-to-build file with a detailed explanation of the CoreAudio folder move.

Good idea, I’ll start one.[/quote]

Excellent! This seems like a good solution, as it will also work for other projects that are built in 10.6, that people are trying to build in 10.5. I don’t know of any other projects right now, but I’m sure they will come into being someday.

Sean Costello