Ideas for Google Summer of Code 2012?

Hi Juce Community,

Applications for Google Summer of Code 2012 are about to start, and Julian agreed that it’d be very cool to have students work on Juce during that time.

[size=150]Presentation[/size]

For those of you who’re not familiar with SOC, it’s a big Google-funded event where they pay selected students to work on Open Source projects. The goal for google is to improve open source projects, some of them they might use themselves, and certainly also to discover future hires.

Applying students who get through the selection process get to work on interesting projects, they get payed quite a lot (around $5K), they obviously improve their resumes and in the process they get used to work with a community and might face problems and requirements they’ve not faced in their studies yet. In a word, for students it’s Bazinga!

For organizations, well, you get free interns! Plus $500 for each project getting through. The only thing to do is to present a convincing application and get the interest from prospective students. I volunteered to do the boring administrative blabbering because it’s (of course) in my interest to see some of these projects get into the trunk :slight_smile: (but if you really want to do it, I won’t fight over it, don’t worry…)

If you need more information, there’s a FAQ on the official page: http://www.google-melange.com/gsoc/homepage/google/gsoc2012

[size=150]First Step: Listing Subject Ideas[/size]

I propose we list subject ideas we might have for students. It’s time for you to dig out the things you’ve never had time to work on. Please mention as well if you’d be OK to mentor a student working on the given subject. Knowing that according to Google, mentoring can take up to 5 hours a week. But to be honest, I know a couple of students who did the program in the past years and they never required that much attention.
All you have to do is to introduce them to the world of juce, guide them and check their work (fill evaluation forms). You still need the technical ability to code in correct C++ though, because if the student gets stuck, and no one on the forum can help, you’ll have to provide the support. But we can organize ourselves to give each students 2 mentors. That’s actually recommended by google and would also give us less to do.

I start with a couple of ideas I saw on the forum, and I’ll update the post with your ideas:

Formats / Protocols
[list]
[]1.VST3 wrapper[/]
[]2.VST3 hosting[/]
[]3.OSC support[/]
[]4.LV2 Hosting - Host LV2 Plugins[/][/list]
Algorithms / Data Structures
[list]
[]5.beat detection algorithm[/]
[]6.Audio to MIDI conversion[/]
[]7.“Smart Musical Arrangement” assistant[/]
[]8.multicore AudioProcessorGraph processing[/][/list]
Visual Components
[list]
[]9.Music Score support[/]
[]10.Office 2010-like “Ribbon toolbar”[/][/list]
Graphics
[list]
[]11.PostScript Renderer[/]
[]12.Direct2D Graphics Renderer - Hardware accelerate graphics rendering on Windows, required for WinRT/Win8ARM support[/][/list]
Core
[list]
[]13.Shared Memory (multi-platform) class[/]
[]14.WinRT Port - So Juce Applications can run on Windows 8 ARM[/]
[]15.NaCl Port of Juce[/]
[]16.Complex languages rendering on Linux/Android using Pango[/]
[]17.PostScript Parser[/]
[]18.Wayland port of Juce. Wayland is the next-gen X server and will hit 1.0 release in few month[/]
[]19.Integrate juce with the OS specific accessibility APIs (VoiceOver on mac etc), allowing blind users to use juce apps[/][/list]

Other ideas? Support for a specific (open) format? Algorithms? C++11 fun stuff?

Since this is Google, something that may interest them would be an NaCl port of juce. I’ve always wished I had time to have a go at that myself.

Don’t have time to mentor, but I’ll certainly add my juce wishlist.

[list]
[]WinRT Port - So Juce Applications can run on Windows 8 ARM[/]
[]Direct2D Graphics Renderer - Hardware accelerate graphics rendering on Windows, required for WinRT/Win8ARM support[/]
[]VST3 Hosting - Host VST3 Plugins[/]
[]Pango Support - So Juce can support complex text languages on linux and android[/]
[]PulseAudio Support - So we don’t have to keep shutting down PulseAudio to use audio hardware on linux[/]
[]JACK Midi Support - Complement existing JACK Audio Support[/]
[]LV2 Hosting - Host LV2 Plugins[/][/list]

AAX wrapper would be nice too, but is probably not possible as AAX is not open source, right?

Exact! I thought about it then it got out of my mind. They’ll love it :wink:

Probably as open as VST… so it should be possible to make a GPL wrapper and let the user download the proprietary stuff on the side. Do you have a link to the SDK or related legal stuff so that I can have a look?

Wasn’t someone already working on this? Yet, I guess it won’t make any harm if another implementation is done.

[quote=“sonic59”]WinRT Port - So Juce Applications can run on Windows 8 ARM
Direct2D Graphics Renderer - Hardware accelerate graphics rendering on Windows, required for WinRT/Win8ARM support[/quote]
Fair enough.

I remember reading that TheVinn was working with people from Freetype to do something related to text rendering as well. Wouldn’t it be worth gathering all the problems related to text handling on all platforms and extract work items from the whole?

[quote=“sonic59”]
PulseAudio Support - So we don’t have to keep shutting down PulseAudio to use audio hardware on linux
JACK Midi Support - Complement existing JACK Audio Support[/quote]
Could you please enlighten me on this? What kind of work would jack midi support require? Is it just the implementation of new callbacks or bigger stuff? In other words, do you think it is worth making a person work fulltime on this for the whole summer?
Regarding PulseAudio, does it act as a replacement to JACK? From what I (quickly) read, it doesn’t seem to be as fit for realtime audio as JACK.

MusicScore classes
VST3 wrapper
AudioConvertToMidi class
IntelligentComposing classes
TabMenuModel class
Printout class
TextRender - more clearly than at present

Supporting AAX will be quite hard. AAX is nowhere near as open as VST. Developers must be approved by Avid before they are even given the AAX SDK. And it is no rubber stamp, many people/small companies get rejected. I find it highly unlikely they will give the SDK to a student.

I believe someone built an LV2 plugin wrapper for Juce. This is different from hosting LV2 plugins.

TheVinn wanted hinted fonts and convinced Jules to make some changes so he could make this happen by using Freetype. He has already completed that work. What I meant was supporting the rendering of complex text languages (arabic, hebrew, hindi, etc.) on Linux and Android via Pango. Such support already exists for Windows/Mac/iOS using platform specific APIs.

Just the implementation of new callbacks I believe. This task would probably only take a couple weeks at most.

PulseAudio and JACK are both sound servers so you could replace JACK with PulseAudio. I don’t think supporting real time applications was ever one of PulseAudio’s primary design goals. It is basically a software mixer that routes sound from different sources to your audio hardware. It takes exclusive control of your audio hardware, so if you try to run a Juce app on a machine that is running PulseAudio, the audio won’t work until you shutdown PulseAudio since the Juce app wants exclusive control as well. PulseAudio is used by many major linux distributions such as Fedora, Ubuntu, Mandriva, Linux Mint, openSUSE, and OpenWrt.

Could you elaborate on those so that I can understand what their goal is? :slight_smile:

Is it also the case if you just want to host an AAX plugin? If yes, then I propose we give up on yet-another stupid closed format…

I get your point, but to me, if you intend to do audio sequencing and other realtime audio applications, you should tailor your system to use dedicated routing servers such as JACK, which was created only in that purpose. This is what ubuntu studio proposes, because it has a different problematic than the usual desktop ubuntu, mandriva, and others. If you modify your juce application to route audio through PulseAudio instead of JACK, I fear you’ll get excessive latency. I agree that it’s better for compatibility reasons so that the “average user” can make sound with your software, but the average linux user should be able to switch to jack. Again, it’s my opinion. I can always add it to the list, but don’t count on me to mentor that :wink:

No, it is worse. Avid doesn’t allow anyone to host RTAS or AAX plugins except themselves.

LCD optimised edge table rendering in LowLevelGraphicsSoftwareRenderer?

IntelligentComposing: This may be an impossible task at present. The advantage of the computer is computing speed, memory and storage capacity far beyond the human. If the computer like humans can learn the skills of composition (write music), programming, etc., (maybe computer neuronic system?) should be a really good thing. At the least, to do myself own music with the software code by me, I don’t need to hard study C++ and JUCE…This topic is so widely, far beyond me expression ability in English.

TabMenuModel: just like the Office 2010 tabbed menu system, not a pop-up menu. Use custom ToolBarItem technology of JUCE should be able to achieve, but too complicated.

Printout the class: document printing to paper or printout as PDF…

TextRender: still less likely to achieve the desired, because Jules focus of attention will not this. everyone seems to satisfied with JUCE text clarity, in addition expert man such as Sonic59 etc, I feel a bit weird.

Non-tongue exchange difficulties, and the East-West cultural background differences and different ways of thinking, a lot of things I don’t know how to express, the reasons of the poor weight not, be of little importance. these words more likes balderdash, please forgive me.(人微言轻,无足轻重,诸位一笑置之可也)。

Thanks.

[quote=“Andrew J”][quote=“SwingCoder”]
TextRender - more clearly than at present
[/quote]
LCD optimised edge table rendering in LowLevelGraphicsSoftwareRenderer?[/quote]
I don’t quite understand what you said about and I haven’t studied this class: LowLevelGraphicsSoftwareRenderer earnestly. Someone once hinted to me, I will learn it carefully in the near future. seem to no relationship of LCD.

thanks.

Don’t worry about cultural background differences, I worked in Asia for long enough to avoid any East-West pitfalls :wink:

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. If we could at least get a tool to generate jazz grids or such, it would already be wonderful. I think software like BandInABox already do similar stuff.

I see. This is called “ribbon toolbar” in office I think. This shouldn’t be that difficult. Probably even a bit boring as it’s mostly graphical layout problems.

Except musical sheets, I don’t really see what I would like to print. But why not…

If anyone could express clearly what the problems are with fonts, text rendering and assimilate, I could probably come up with a bunch of action items… I already understood complex language support was missing on Android and linux, as opposed to other platforms. What else is wrong? Crispiness on LCD screens? Low level renderer missing feature?

  • 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.

  • 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.

  • 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.

What SwingCoder is referring to when he says “TextRender - more clearly than at present” is the fact that Juce’s text rendering on Windows does not look like other native Windows applications. The reason for this is because on Windows, Juce renders text itself via it’s own internal software renderer and without font hinting. This is different from native (Pre Windows 8 ) Windows applications which render text via GDI, with font hinting and ClearType. Jules has stated unequivocally in the past that he will not be adding font hinting to Juce himself. TheVinn really wanted font hinting so he created a separate MIT licensed library that utilizes FreeType to allow for the use of hinted fonts in Juce. Still, even when using this library, text will not look like other native Windows applications because you are still not using GDI and ClearType.

The only way for it to ever look the same is for someone to implement a GDI version of LowLevelGraphicsContext. While this is totally possible, I believe this is a waste of time, GDI is already deprecated and it has been completely dropped from the new Metro API’s in Windows 8. Direct2D and DirectWrite is the new and vastly improved way to do 2D text rendering in Windows. They are both part of the new Metro API’s and it is highly likely they are used to render all text in Windows 8. Juce already supports DirectWrite so the only thing that needs to be done is for someone to write a Direct2D LowLevelGraphicsContext. Once this is done, text will look exactly like other native Windows 8 applications and will be rendered using Direct2D, with font hinting and the latest version of ClearType (which is superior to the older version available in GDI).

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

:mrgreen: I bring your letter to Santa, but I won’t build all the toys for you…

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

PostScript renderer / PostScript parser. Right.

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. ?

Hmmm. Open-source related project. I like that :slight_smile:

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. :stuck_out_tongue:

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.

I cast my vote to the “People Republic of Juce”. I hope the Party is ok with that :smiley:

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 ! :smiley:

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 :slight_smile:

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