| StoreTags: cocoa, coding, timestretch
Author: cbit on July 30 2008 Viewed 1508 times. 7 people liked this blog. You can rate it below if you haven't already.
-->
I'm always on the lookout for new ways to stretch and bend audio. In particular i'm interested in approaches that integrate well with my regular ableton Live workflow.
I noticed that scuzzphut has released a windows vst plugin called Rubberizer (bottom of the page) that's a wrapper for the cross platform RubberBand timestreching app.
This got me wondering whether there were any front-end GUIs for rubberband, that would run on OS X. I couldn't find any. So i was wondering how complicated it would be to make one, and thought id ask here in case anyone has a clue.
Here's how i'm imagining a 'proof of concept' version of this hypothetical app would work.
1. You'd be working in Live, in the 'Replace Sample Files' window youd' click the Edit button for the sample you were interested in.
2. The sample would open in this cocoa app.
3. The cocoa app would have a number entry field representing the % that the sample should be stretched by. Clicking a 'process' button would stretch the sample by the appropriate amount and save it.
4. Back in live you'd click the edit button again to bring the stretched sample back online.
Is this possible? if so, what technologies should i be investigating if i wanted to build this wrapper app? I'm guessing XCode, objective C and Cocoa. Is that about right?
(One question that might seem sensible to ask is "Why not use an existing audio editor?" - The answer is that I'm interested in making the process of timestretching audio as fast as possible. The audio editors i've seen require too much mousing and clicking to complete an operation like this.)
Thanks! | |
Comments
07/30/08
+
PM |
QUOTE |
PERMALINK |
REPORT
daswesen
yeah, it should be pretty simple using cocoa and wrapping aorund the c code. get through the tutorials for objective C and cocoa by apple, they are pretty neatly done. You should be able to do this with not too much coding.
07/30/08
+
PM |
QUOTE |
PERMALINK |
REPORT
em978
daswesen is right. Though objective C 's syntax is a little funky.
07/30/08
+
PM |
QUOTE |
PERMALINK |
REPORT
cbit
thanks guys, good to know i'm not barking up entirely the wrong tree.
07/30/08
+
PM |
QUOTE |
PERMALINK |
REPORT
fakeBlooper
i'm no cocoa expert but i think it'd be tricky. how are you going call this rubberband app through live's gui?
some have reported that they have the "official" (not endorsed, but supported by abes) live-api working on osx: link
i'd get on their list and snoop around there. you could still use objc/cocoa for the actual rubberband app with python for the gui hacking.
07/31/08
+
PM |
QUOTE |
PERMALINK |
REPORT
cbit
fb: There would be no hacking of Live's GUI. Live already lets you assign an external sample editor to open samples in when you click a certain 'edit' button. This was the mechanism i was hoping to use. Though I don't know exactly what hooks the editor application would have to have in order for Live to be able to use it this way, i'm hoping it will be quite straight forward (i'm imagining that if the app will open a sample when you drag drop one onto its icon, then it should also be targetable by Live as an extrenal editor).
Dunno though. Yes it might be a good idea to look at the Live API too. ugh!
07/31/08
+
PM |
QUOTE |
PERMALINK |
REPORT
daswesen
you won't be able to use the live api to control the editor software, but you could access the current clip information for example. I think the editor just needs to support opening a file passed over the command line, but i'm not entirely sure. The best way to hook into rubberband would be to hook into it's sourcecode, instead of calling the command line tool i think, but the command line way should work well too.
07/31/08
+
PM |
QUOTE |
PERMALINK |
REPORT
cbit
"he best way to hook into rubberband would be to hook into it's sourcecode"
I'm imagining that this would involve including the rubberband code into my build (so it becomes 'part of' my app) is that the correct way to think about iit?
I'm thinking about getting this book to try to get up to speed on cocoa
link
I'm also going to work through the apple tutorials (currency converter) but i'm already noticing that they seem to be glossing over alot of detail so far 
07/31/08
+
PM |
QUOTE |
PERMALINK |
REPORT
fakeBlooper
oh sh#t i never noticed that! i've always made do with the native stretching... hardly use an external editor at all.
personally, i can't wait to see what comes out of the cycling74/abelton collab efforts. i have a feeling it's just gonna be something like a customizable dashboard for midi controllers, but imagine the possibilities of a scripting window where you could reference every clip/scene/note/parameter in the session... or a "roll your own" pluggo lite* built-in. hell, fruity comes with synthmaker... why not?
but what i'd like most is a native midi loopback device to show up as a virtual device. too many possibilities.
08/01/08
+
PM |
QUOTE |
PERMALINK |
REPORT
daswesen
yes cbit, including the sourcecode. but i think the command-line calling option is good as well, it's just a bit more messy in my programming brain
08/01/08
+
PM |
QUOTE |
PERMALINK |
REPORT
Bruno
If you're going to be using the existing app, and all you're doing is inputting a value and sending that as a command line parameter to Rubberband, you could probably pull this off in Applescript...
08/01/08
+
PM |
QUOTE |
PERMALINK |
REPORT
cbit
Bruno said: "If you're going to be using the existing app, and all you're doing is inputting a value and sending that as a command line parameter to Rubberband, you could probably pull this off in Applescript..."
What i'm wanting is to use the edit-sample-in-external-editor button in live to open this other app with the sample pre-loaded, so minimum clicks and navigation would be needed. I guess that wouldn't be possible using applescript (?).
08/01/08
+
PM |
QUOTE |
PERMALINK |
REPORT
ejectorset
i dunno, applescript can definitely handle a file being passed by dropping it on an apple script's icon, it might be able to handle parsing the filename if given to it as an argument (assuming that live's external editor does that) i would figure out a really clear and concise way of asking that question and post it over on the applescript forums.
applescript is really easy to use and quite capable.
i would think once live passes the file it just waits until the file is saved and closed then reloads it. you can definitely save and close and interact with the command line in applescript. the only catch i see is handling the file argument at launch.
08/01/08
+
PM |
QUOTE |
PERMALINK |
REPORT
cbit
interesting, thanks. i'll look into that.
08/01/08
+
PM |
QUOTE |
PERMALINK |
REPORT
ejectorset
after work i could probably whip up a simple applescript for you to check out that simply outputs the name of the file dropped on it via growl so you could poke around in that and also see how it responds to being used as live's external editor.
i already have some similar stuff for copying files across a network i could strip it from. the good thing about applescript is you can save them as standalone applications.
08/01/08
+
PM |
QUOTE |
PERMALINK |
REPORT
cbit
that'd be great! you can use this address to send it over: applescript.10.cbit AT spamgourmet.com
Register / login
|
^
EM411 is Copyright 2001-2008 EM411.com
All rights reserved. | Contact | RSS
|
