- This topic has 4 replies, 2 voices, and was last updated 10 years, 11 months ago by
.
-
Posts
-
Hello, it’s me again 😉
Like the other times I came here, I wanted to checkout the newest Ctrlr version to play with (e.g. the new TX7 panel) because I had a little time left right now.
The last times this window (in time) was closed as soon as I had managed to complie Ctrlr so I had no time left to actually use it.
This time I didn’t even come this far…
I wrote the script posted earlier in another thread to semi-automate the building process and hopefully speed it up a lot. It helped, but was definately not enough.Today I updated the script to use your new repository which I had not known about hadn’t I stumbled upon it last time and modified it to use the copy of Juce you distributed with the code.
Then I still got errors in conjunction with luabind. Admittedly I use boost 1.53 so that could have been the problem, but even with your boost.zip it still put out the same error (../../../../Source/Lua/luabind/src/class.cpp:29:24: Error: Declaration does not declare anything [-fpermissive]
LUABIND_API detail::nil_type nil;
— if you find that helpful in any way)Also I noticed that I ran out of RAM when using “make -j32” (32 core AMD, 64GB RAM btw.) That was quite unfamiliar 😉
All in all I have the impression Ctrlr might have a little to many dependencies and might even be considered “bloated”. Especially if you – atom – are the only person maintaining it. I still can’t imagine how you do it, but then I’m not a software developer.
And the whole point of using juce also seems to be a little in vain (at least from my point of view as a linux user), when you don’t supply regular updates of your linux binaries or at least make it somewhat managable for a non-softwaredev. to compile it theirselves.
The next point I see is Documentation which right now is nearly nonexistent.
If you could set up a wiki of some sort I’d be happy to share some things I have leard about Ctrlr and so would probably others. E.g. it’s not nice if the only way to know how to get your recent code is to have stumbled upon you mentioning the new repo in a totally unrelated thread in the forum. At least make the small but neccessary bits available at one fixed location (I have noticed the “Documentation” subpage… although I would recommend something wikilike for users to be able to contibute to the Doc. easily, it would be ok if these information were to be found there.)Please do not interpret this post as an attack on your work. I’m simply frustrated that it has to be so complicated to impossible to use your program which I so desperately would like to! And I would like to help improve that situation!
Regards, the fellow Roman
The documentation is better then it was trust me, there was nothing. At least i wrote a tutorial and some expression info. As for a WIKI, there was one noone really used it.
AS for the building. I can’t really explain the point of using JUCE, too much to say. BLoated? i saw programs that do less using more libraries. I’m using 3 Juce, Boost, Luabind. All of them are included in the repository.
You should not run make -j 32. When building “BOOST” takes a shit load of memory, all the headers are compiled in memory and take loads of it, unless you use precompiled headers (witch i do, it minimizes memory usage and speeds up the builds process to seconds). And no i don’t do linux, i barely can do MAC builds. Just doing the builds is not enough someone should test them and i just don’t have the time.
That boost error is known to me, it’s actually a luabind error. I’ll try to sort that out asap. I can’t really use Linux on my PC, it lacks support for my audio/midi hardware and it’s hard to work for a longer period without that stuff working.
Yes, 3 libraries actually sound reasonable, but there are still plenty source files in (to me) a somewhat chaotic folder structure. “Bloated” was referring to that and the impression I got from compiling. If you could simply state what each folder is there, that could be helpful to possible contributors. E.g. there seem to be more than one folder called “luabind” which can be a little confusing.
That’s why I suggested a wiki, to explain how to get your code, how to compile it in a way that allows for automation and maybe even how Ctrlr works internally. And of course how to set it up properly, how to create panels etc. And keep it up to date! No more crawling through forum posts. 😉
It’s a shame nobody used the wiki last time, but be assured you would have at least one regular user this time.Also I can offer you to test Ctrlr on linux more regularly, if that helps.
By the way, have you considered releasing stable versions again?
If you just freeze the code of a “good” revision from time to time and apply bugfixes only, that wouldn’t hinder developement too much, would it?
Maybe I can help you there as well, at least by testing.And thanks for your promise to look into the luabind stuff.
What Audio/MIDI hardware are you using, MOTU? 😉EDIT: I just had a closer look in your Documentation. “Getting started” seems a little understated. Nice 🙂
If you don’t want to develop anything in Ctrlr then the information about directories file names etc. is useless to you, how you build it is the question.
Too many files ? I follow a certain method and i stick to it i saw many projects follow the same rules. I don’t see how the count of source files can affect anything in the project.
I will create a short document describing what’s what in the directory structure, there are no doubles in terms of directories, you only see it “double” if you actually look at it closely you will notice why there are two luabind directories.
- The forum ‘Using Ctrlr’ is closed to new topics and replies.