Ideas for Google Summer of Code 2012?

[Shlomi]

Dri you finally found the elegant way for us to post our Juce-wish-list, nice..

[Dri]

Dri you finally found the elegant way for us to post our Juce-wish-list, nice..

I bring your letter to Santa, but I won't build all the toys for you...

Juce already supports DirectWrite so the only thing that needs to be done is for someone to write a Direct2D LowLevelGraphicsContext.

Thanks for the clear explanation. Better focus on the new technologies then as it would obviously gather more interest from google/students.

* Finish the PostScript renderer. This would allow printing at no cost, since all platform allow sending postscript directly to the printer.
As an additional bonus, add some GZipOutputstream in the deal and write a PDF writer.
* Ideally have a PDF/Postscript parser. Again, the main force of Juce is the simplicity/flexibility of its vectorial engine and being able to use PostScript as a serializer would be awesome to my point of view.

PostScript renderer / PostScript parser. Right.

* Improve the performance of Juce. Globally Juce is alread optimized for being usable in most case, but there is probably multiple case where bottleneck could be found and optimized away.

Global performance study. That might be a little too wide for a summer. What about splitting it to: network performances optimisation, rendering performance optimisation, data structures performance optimisation, etc. ?

* Wayland port of Juce. Wayland is the next-gen X server and will hit 1.0 release in few month, and in the next semester Linux distribution will start throwing X away. So better anticipate the change and start working on this now.

Hmmm. Open-source related project. I like that

[SwingCoder]

Thanks so much posting here, I could learn a lot of knowledge, very gratefully. Thanks Dri's encouragement.

Many years ago, when I just started to study composition, the most I confused the issues is mathematics. Such as major and minor chord structure, check harmony primary errors in parallel fifth and parallel octaves etc.. All of which was simple math problem in fact. The rules of music theory summed up whats modes wasn't feasible, but didn't tell people what kind of models processing is good to meet the more emotions if we needed. Someone might say there are too many permutations and possibilities, but many years of musical career, I firmly believe that an experience, if divided the emotion in all of the music segments, each always only one is the most classic.

If Tesla still alive, according to his understand how easy to play vibration and frequency, the music revolution will be more thorough. Put it another way, perhaps we can understand or rebuild the entire music system that use mathematical models and physics models. The mathematical principles of this system may not be too complicated, just hanging in the mist of somewhere at present. The fourth apple is expecting hit a lucky guy. I hope that he has be from the People's Republic of JUCE.

Band-in-Box and Jammer... well, in order not to generate noise, we must rely on two aspects, the one: must manually enter the chords, and the second: accompaniment pattens is fixed, requires the programmer or user to complete this step . FLStudio and REASON were another kind of ideas, but they still didn't fundamentally understand and solve problems in the production of music, let alone intelligent. For example: tell the software that we need some lively jazz or a sad ballad. TONICA proposes a conceptual about neuron learning function, I find it very interesting.

Unfortunately, I can be completed a large orchestral works or arranger and recording of the whole album within a very short time, but as of now, I even can't fully understand JUCE-DEMO source code and still don't know what the objects of what classes are how to cooperate with each other to complete the recording or play sounds. Talk about these, it is trespass, ashamed of the pole.

Thanks X-Ryl669 and Sonic59, I personally think these explanation very professional and clear. I want to add is: the text rendering may not be issue for Latin alphabet, but for the hieroglyphs such as Chinese that is a serious problem. There are two reasons:

First, the strokes more sparse of the Latin alphabet, even if the text very small still can also see . but in this case, Chinese characters can't, such as: 龍飛鳳舞 錦繡鴻運...

the second: the westerners language and reading nerve center be located a same region in brain, while Asians are located separate in the left brain and right brain, we must be reading careful in order to truly understand. English pay attention to the logical, accurate reasoning, clarity and vividly, the language is very complicated, but the alphabet is very simple. Hieroglyphs pay more attention to implication, context, mood and ambiguous. The language of comprehensible is very simple, but the text is very complicated. I think this is a real cultural background differences.

[dinaiz]

I cast my vote to the "People Republic of Juce". I hope the Party is ok with that

My vote goes, by far, to "Multicore AudioProcessorGraph processing"
Why ? First because I'm a selfish bastard doing audio applications, and I'd need that more than the rest !

Also because while the others ideas are very good, we have to make ONE choice and other choices either :

- already exist in 3rd party libraries ("beat detection algorithm", OSC support, Shared Memory (multi-platform) class, ...)
- or are very specific (Windows 8 ARM port, Complex languages rendering on Linux, LV2 plugins ...)

I still firmly believe that while Juce is a very good library overall, it's major selling point over other libs (Qt and so on ...) is the audio stuff, and the multiprocessor audio graph would beniefit anyone using an audio processor graph, as a drop in replacement.

Then because the topic is complex enough for a summer of code, while not being too complex for the brillant students who get to do the SOC .

Just my 2 cents anyway , but I hope some of you see it like that too

[jpo]

Something that would be interesting, but maybe not easy or even not possible at all, would be to integrate juce with the OS specific accessibility APIs (VoiceOver on mac etc), allowing blind users to use juce apps

[Dri]

My vote goes, by far, to "Multicore AudioProcessorGraph processing"

It's not about voting, it's about proposing yourself as a Mentor. The remaining subjects will be those with 2 volunteer mentors.

[falkTX]

I never got into a GSoC project before, so I don't know exactly how this works...
but anyway, since I already started some work on the LV2 wrapper (plugins only so far, not hosting), I want to apply to it.

When and how should I do it?
Thanks in advance.


PS: 2 screenshots
---- ardour3 and wolpertinger

---- lv2rack and eqinox

[Dri]

I never got into a GSoC project before, so I don't know exactly how this works...
but anyway, since I already started some work on the LV2 wrapper (plugins only so far, not hosting), I want to apply to it.

You mean apply as a student? If so, you have to wait until the students application process starts. For the moment it's still organizations application process until the 10th of March or so. Because they have to validate our application to the program. Then you will be able to apply to google directly.

If you plan to work on a subject which already has mentors, you can already start to contact them and talk about the subject if you want. If there is no mentor attached to your project of interest, you should try to find one among the forum members. And if you want to work on a totally different subject, propose it, and find someone to mentor you.

Is that what you wanted to know?

[falkTX]

I never got into a GSoC project before, so I don't know exactly how this works...
but anyway, since I already started some work on the LV2 wrapper (plugins only so far, not hosting), I want to apply to it.

You mean apply as a student? If so, you have to wait until the students application process starts. For the moment it's still organizations application process until the 10th of March or so. Because they have to validate our application to the program. Then you will be able to apply to google directly.

If you plan to work on a subject which already has mentors, you can already start to contact them and talk about the subject if you want. If there is no mentor attached to your project of interest, you should try to find one among the forum members. And if you want to work on a totally different subject, propose it, and find someone to mentor you.

Is that what you wanted to know?

Yes, thanks.

So I basically have to wait and see if the LV2 wrapper gets accepted as project, correct? If yes, I'll apply to it then.
The LV2 wrapper is pretty much done though, but needs some cleanup (LV2 just keeps changing....)
LV2 hosting is a totally different story, it needs RDF parsing (the official lilv libs are not so great in my opinion).

[ans]

Great things going on here. I'd like to add my 2 cents regarding "Intelligent Composing":

This is a great idea and would really fit in an academic work! Lots of work to do in the AI field regarding this subject.

I've been working on this for 10+ years now, using the most capable and exotic tools available, and it still took me at least 7 years to get a working product running. This is such a huge and challenging field of research, it would greatly exceed the scope and purpose of the Juce library. I'd also say AI and C++ do not go together very well. You'd need a more expressive dynamic language for that. Just to be clear: I don't mean Intelligent Composing could not be based on Juce, I just say it should probably not be a part of the Juce library itself.

Concerning the "AudioToMIDI" suggestion, I'd also say this is application domain rather than tool domain. Given the indeterministic nature of the task, there are many different approaches to the problem and multiple viable solutions to each of them. I'd rather like to see many Audio to MIDI tools based on the Juce library, then only one of these integrated into the library.

Just my 2 ct.

[dinaiz]

Concerning the "AudioToMIDI" suggestion, I'd also say this is application domain rather than tool domain. Given the indeterministic nature of the task, there are many different approaches to the problem and multiple viable solutions to each of them. I'd rather like to see many Audio to MIDI tools based on the Juce library, then only one of these integrated into the library.

What abouyt the licence ? Juce's licencing model is pretty nice (free for open source, paid for commercial apps), but I don't think you can release any code based on juce under a more liberal licence (like MIT), can you ?

You'd have to release it under GPL and then nobody could use it for comercial projects. Or maybe LGPL would work with juce ?

[Dri]

Dinaiz, please read the FAQ before asking a thousand questions!
Regarding the code copyright, it clearly states that the organization can retain the copyright of the code produced by students.

On the other hand, I don't know how stallmanish they will be with the double license thing. The way I see it, it's not a problem at all because the goal of GSoC is to increase the amount of open-source software available, which will be effectively achieved. All the code published under GPL will always be available to the public. Anyone can fork Juce at any time and make modifications that Jules would not be authorized to sell as part of the double license without the auhorization of the copyright owners.

The only consequence of the commercial license on the code is to block the "viral" aspect of the GPL: force anyone modifying or including it in a commercial project to bundle their code with the binary. As far as I know, liberal licenses like MIT or BSD don't force commercial users to bundle their code either, and they're perfectly eligible to GSoC...

They could also argue that Jules can make money with the code made by others, but then, we can say the same about Fedora/RedHat, Chromium/Google, and any other company selling services around open-source code.

As of the tool vs applicative level question: internships don't necessarily have to extend the library. They can be prototypes and experiments. In fact, in such cases, we could even let the student keep the copyright of its material and use the study he did to do it our way from scratch.

[dinaiz]

Dinaiz, please read the FAQ before asking a thousand questions!
Regarding the code copyright, it clearly states that the organization can retain the copyright of the code produced by students.

Then read my questions properly!! Haha just kidding
I was referring to the case where something is developped outside of Juce (see ans message above)

[Dri]

Anyways, it's unfortunately not for this year:

Thank you for submitting "Raw Material Software" organization application to Google Summer of Code 2012.
Unfortunately, we were unable to accept your organization's application at this time.
We received many more applications for the program than we are able to accommodate,
and we would encourage you to reapply for future instances of the program.

Best regards,

Google Open Source Programs

Thanks to all of you who volunteered and suggested ideas.

[jules]

Ah well.. Maybe next year! Thanks everyone!