ugh leisner

Can anyone recommend me someone in Berlin that I can ask for help on a app I'm building?

maxmsp-guru-in-berlin-with-java-skills

I am not a Java expert but maybe I can help.

Contact me offlist (*not* via the forum) for more infos.

> Can anyone recommend me someone in Berlin that I can ask for help on a app I'm building?

Hi.
I am not a Java expert but maybe I can help.
Contact me offlist (*not* via the forum) for more infos.

ono wrote:
> Hi.
>
> Can anyone recommend me someone in Berlin that I can ask for help on a app I'm building?
>
>  - Kristoffer
>
>


really depends on what you need. I do quite a bit of Max, MSP; less Jitter, and used to program java at work. wouldn't call myself a guru in either one of those two.

The app is an adaptive version of a music album. I'm using various rules such as time, weather data, user input, mic & cam input etc. to activate various changes in the music such as alternative intros and outros, hidden songs, alternative arrangements etc. I've been recommend to adapt Andrew Bensons MoviePicker article (

https://cycling74.com/story/2008/9/5/16230/12047)

 to audio use in order to get stability and to be able to use mp3's, the audio in .wav would simply take up way too much hd space. That's why i need some java help.

The app is an adaptive version of a music album. I'm using various rules such as time, weather data, user input, mic & cam input etc. to activate various changes in the music such as alternative intros and outros, hidden songs, alternative arrangements etc. I've been recommend to adapt Andrew Bensons MoviePicker article (https://cycling74.com/story/2008/9/5/16230/12047) to audio use in order to get stability and to be able to use mp3's, the audio in .wav would simply take up way too much hd space. That's why i need some java help.


Hhmmm, as far as I can see, Andrew introduced the "hidden" SQLite object which is not accessible with standard Max means and therefore requires JavaScript (which is not Java :-). Main reason is to use a more stable and extensible backend for data storage.

Adapting it to audio wouldn't be the issue here, and you wouldn't need Java(Script) for that. In the article, video(file) names and tags are handled, the actual video stuff is plain old jit.qt.movie, and in your case, would be buffer~ or equivalent.

The other issue about mp3 vs. wav is also on a different page. mp3's need to be imported which takes time and therefore might not be appropriate for you. anyway, not related to Java.

Quote: ugh leisner wrote on Thu, 19 February 2009 08:21

----------------------------------------------------

> The app is an adaptive version of a music album. I'm using various rules such as time, weather data, user input, mic & cam input etc. to activate various changes in the music such as alternative intros and outros, hidden songs, alternative arrangements etc. I've been recommend to adapt Andrew Bensons MoviePicker article (

Quote: ugh leisner wrote on Thu, 19 February 2009 08:21
----------------------------------------------------
> The app is an adaptive version of a music album. I'm using various rules such as time, weather data, user input, mic & cam input etc. to activate various changes in the music such as alternative intros and outros, hidden songs, alternative arrangements etc. I've been recommend to adapt Andrew Bensons MoviePicker article (https://cycling74.com/story/2008/9/5/16230/12047) to audio use in order to get stability and to be able to use mp3's, the audio in .wav would simply take up way too much hd space. That's why i need some java help.
----------------------------------------------------


I know about the java vs javascript, my mistake;). I know that mp3's has to buffer, which is okay. And as I've understood javascript it would be possible to buffer all audio when opening the app, and in this way avoid pauses between tracks. I could be wrong, my javascript knowledge is very basic...

Quote: monohusche wrote on Fri, 20 February 2009 23:39

> Hhmmm, as far as I can see, Andrew introduced the "hidden" SQLite object which is not accessible with standard Max means and therefore requires JavaScript (which is not Java :-). Main reason is to use a more stable and extensible backend for data storage.

> Adapting it to audio wouldn't be the issue here, and you wouldn't need Java(Script) for that. In the article, video(file) names and tags are handled, the actual video stuff is plain old jit.qt.movie, and in your case, would be buffer~ or equivalent.

> The other issue about mp3 vs. wav is also on a different page. mp3's need to be imported which takes time and therefore might not be appropriate for you. anyway, not related to Java.

> Quote: ugh leisner wrote on Thu, 19 February 2009 08:21

> ----------------------------------------------------

> > The app is an adaptive version of a music album. I'm using various rules such as time, weather data, user input, mic & cam input etc. to activate various changes in the music such as alternative intros and outros, hidden songs, alternative arrangements etc. I've been recommend to adapt Andrew Bensons MoviePicker article (

I know about the java vs javascript, my mistake;). I know that mp3's has to buffer, which is okay. And as I've understood javascript it would be possible to buffer all audio when opening the app, and in this way avoid pauses between tracks. I could be wrong, my javascript knowledge is very basic... 

Quote: monohusche wrote on Fri, 20 February 2009 23:39
----------------------------------------------------
> Hhmmm, as far as I can see, Andrew introduced the "hidden" SQLite object which is not accessible with standard Max means and therefore requires JavaScript (which is not Java :-). Main reason is to use a more stable and extensible backend for data storage.
>
> Adapting it to audio wouldn't be the issue here, and you wouldn't need Java(Script) for that. In the article, video(file) names and tags are handled, the actual video stuff is plain old jit.qt.movie, and in your case, would be buffer~ or equivalent.
>
> The other issue about mp3 vs. wav is also on a different page. mp3's need to be imported which takes time and therefore might not be appropriate for you. anyway, not related to Java.
>
> Quote: ugh leisner wrote on Thu, 19 February 2009 08:21
> ----------------------------------------------------
> > The app is an adaptive version of a music album. I'm using various rules such as time, weather data, user input, mic & cam input etc. to activate various changes in the music such as alternative intros and outros, hidden songs, alternative arrangements etc. I've been recommend to adapt Andrew Bensons MoviePicker article (https://cycling74.com/story/2008/9/5/16230/12047) to audio use in order to get stability and to be able to use mp3's, the audio in .wav would simply take up way too much hd space. That's why i need some java help.
> ----------------------------------------------------
>
>
----------------------------------------------------


okay got you, just not sure if it will work that way.

mp3 is a compressed format, importing it into a buffer is basically decompressing it back into a raw format (like wav), just with less quality. If you want to buffer the uncompressed audio, then you are effectively keeping the "wav"/raw files in memory which should be a bigger issue than your original problem which was not having enough hd space for the wav files.

I understand your point. The main reason for mp3's / general amount of data is that the app needs to be downloadable. So decompressing the mp3 files actually isn't as big a problem as a 5 gb download app.

But the sound quality ting could be an issue.. What consequences does the decompressing have on the sound quality?

ugh leisner wrote on Sun, 22 February 2009 19:21

I had thought that making a .zip of the app would help with this, but wav files seem to not compress very much, so it's not much help there. As far as the sound quality, my understanding is that once you've compressed, it's at a new (lower) level of quality (assuming you did mp3 or similar that's lossy). So the decompression itself shouldn't alter the quality, it's already been degraded. According to Wikipedia there is a tiny amount of "rounding" which occurs during decompression but its effect is negligible.

If you use a high bitrate (like 256 kbps) with the mp3 you'll get very good-sounding audio in my opinion, and this is about 20-25% the original size. I think mp3PRO will give you even more bang for the bandwidth, but it's possible that additional codecs would be needed to play it. Along those lines you could go the FLAC route to ensure original quality while reducing the file size by about 60%. However, you'd need the user to decompress all the files manually (unless you know a clever workaround), which may be unacceptable... though there's an easy "batch" command in the FLAC Frontend software.

ugh leisner wrote on Sun, 22 February 2009 19:21I understand your point. The main reason for mp3's / general amount of data is that the app needs to be downloadable. So decompressing the mp3 files actually isn't as big a problem as a 5 gb download app.

If you use a high bitrate (like 256 kbps) with the mp3 you'll get very good-sounding audio in my opinion, and this is about 20-25% the original size. I think mp3PRO will give you even more bang for the bandwidth, but it's possible that additional codecs would be needed to play it. Along those lines you could go the FLAC route to ensure original quality while reducing the file size by about 60%. However, you'd need the user to decompress all the files manually (unless you know a clever workaround), which may be unacceptable... though there's an easy "batch" command in the FLAC Frontend software.


Max/MSP guru in Berlin with Java skills?