Comments by pp
hello again, pp here.
@everyone: May 2011 device updated to version 1.0.1, including all previously mentioned bugs fixed and many new features / more stable design.
let me know how you get on,
- pp .
@everyone: May 2011 device updated to version 1.0.1, including all previously mentioned bugs fixed and many new features / more stable design.
let me know how you get on,
- pp .
@Netrik and others, apologies for relative silence:
version 2 is here, uploaded May 2011. Your bugs/issues are fixed and many new features are added.
Enjoy / let me know how it goes...
- pp .
version 2 is here, uploaded May 2011. Your bugs/issues are fixed and many new features are added.
Enjoy / let me know how it goes...
- pp .
hi st235,
glad to hear you have been using these things.
yes, live 8.2.2 + 5.1.8 not only broke quite a few things but also rendered some patching (workarounds) superfluous. however, some of it is to do with the new <empty> message - if you search the ableton m4l forum you will find a set of downloadable abstractions as a fix - these will apparently be included in max 5.1.9 or above.
with regards the bpatcher issue - just click the unfreeze button on the device (after opening in edit mode) and all 'frozen' subpatchers (including the bpatchers) will be unpacked to a folder on your desktop. you can edit everything from here. make sure you 'save as' on everything and manage all your path dependencies properly.
at the moment i am about 80% through a massive update/remake of my 'gLeechFOs' device which addresses all these issues and much much more. watch this/that space. i will get to work on 'Anti-lope' shortly after that.
in the mean time, there are envelope-following to parameter-control devices, and lfo's of course, included with the 8.2.2 / 5.1.8 updates, by manuel poletti, which are excellent of course.
hope this helps for now at least...
glad to hear you have been using these things.
yes, live 8.2.2 + 5.1.8 not only broke quite a few things but also rendered some patching (workarounds) superfluous. however, some of it is to do with the new <empty> message - if you search the ableton m4l forum you will find a set of downloadable abstractions as a fix - these will apparently be included in max 5.1.9 or above.
with regards the bpatcher issue - just click the unfreeze button on the device (after opening in edit mode) and all 'frozen' subpatchers (including the bpatchers) will be unpacked to a folder on your desktop. you can edit everything from here. make sure you 'save as' on everything and manage all your path dependencies properly.
at the moment i am about 80% through a massive update/remake of my 'gLeechFOs' device which addresses all these issues and much much more. watch this/that space. i will get to work on 'Anti-lope' shortly after that.
in the mean time, there are envelope-following to parameter-control devices, and lfo's of course, included with the 8.2.2 / 5.1.8 updates, by manuel poletti, which are excellent of course.
hope this helps for now at least...
hi all. pp here.
eltnet, thanks! give me more opinions ideas if you have them.
vampireangel and all: i have a better updated version of this on the go, using poly~s etc, and also separated the glitch part from the lfos part into separate devices, together in a simple rack. hopefully uploading soon, WITH documentation...
pp.
eltnet, thanks! give me more opinions ideas if you have them.
vampireangel and all: i have a better updated version of this on the go, using poly~s etc, and also separated the glitch part from the lfos part into separate devices, together in a simple rack. hopefully uploading soon, WITH documentation...
pp.
hello everyone, pp here, 13th feb 11.
apologies to all, especially anybodyhuman and zigzag.
the story - i suspect the previous beta works better than what is currently uploaded... i posted the current beta to include the midi send device before going away, thinking i would be one week away from my computer and ended up being 6 weeks due to various non-hilarious life circumstances. so, i am back on track now. i will take a look at all these issues and resolve them very soon.
zigzag - amazing work and thanks, thanks, thanks. i will endeavor to honour your work by getting these boardulator devices working as best as poss as soon as poss. please make requests. i made a couple quirky control decisions that effectively wrap some parameters to the jg.granulate~ object. feel free to readvise opinions. my head a bit spaced, i'll get back to you about the region loop, but as far as i can remember, it selects the PORTION of audio from which to granulate from. grain size etc is on sliders below.
updates soon...
apologies to all, especially anybodyhuman and zigzag.
the story - i suspect the previous beta works better than what is currently uploaded... i posted the current beta to include the midi send device before going away, thinking i would be one week away from my computer and ended up being 6 weeks due to various non-hilarious life circumstances. so, i am back on track now. i will take a look at all these issues and resolve them very soon.
zigzag - amazing work and thanks, thanks, thanks. i will endeavor to honour your work by getting these boardulator devices working as best as poss as soon as poss. please make requests. i made a couple quirky control decisions that effectively wrap some parameters to the jg.granulate~ object. feel free to readvise opinions. my head a bit spaced, i'll get back to you about the region loop, but as far as i can remember, it selects the PORTION of audio from which to granulate from. grain size etc is on sliders below.
updates soon...
@john @analogic76 @tiwe: glad you like it. update + midi-device coming soon...
@tiwe: it is mac only because the third party external i am using is mac only, so no, unfortunately, no pc version coming - my c-coding is non-existent so i cannot compile from source (source is available). if you can, contact the external author and recompile yourself. let me know if you do!
@tiwe: it is mac only because the third party external i am using is mac only, so no, unfortunately, no pc version coming - my c-coding is non-existent so i cannot compile from source (source is available). if you can, contact the external author and recompile yourself. let me know if you do!
hi zlatko. pp here. glad you like it.
when i released this device the parameter assignments DID get saved. however, since then Cycling74 released version 5.1.4 (which i guess is what you are using) which completely broke all pattr objects that reside in subpatchers / abstractions. apparently this will be fixed in the next incremental (5.1.5), but until then we are all screwed.
if you search the various forums this is confirmed. a real shame, but we just have to be patient. i will be updating this all very soon anyway.
when i released this device the parameter assignments DID get saved. however, since then Cycling74 released version 5.1.4 (which i guess is what you are using) which completely broke all pattr objects that reside in subpatchers / abstractions. apparently this will be fixed in the next incremental (5.1.5), but until then we are all screwed.
if you search the various forums this is confirmed. a real shame, but we just have to be patient. i will be updating this all very soon anyway.
hi nofi.
so, i have been using here with a bad messy old computer and seems to be running reasonably smoothly. however, it is beta-like and i will look into all this again very shortly.
i found that with parameter-seq OFF it is very light on cpu and runs very well. if you start using all the parameters that is where your cpu hit will occur, and that is just a m4l issue with 'live.remote~' unfortunately. the biggest hit is when parameter-seqs point to mixer elements for some reason - volumes, pans, sends, x-fader etc. sticking to device parameters will keep your cpu down.
updates soon, thanks for comments.
so, i have been using here with a bad messy old computer and seems to be running reasonably smoothly. however, it is beta-like and i will look into all this again very shortly.
i found that with parameter-seq OFF it is very light on cpu and runs very well. if you start using all the parameters that is where your cpu hit will occur, and that is just a m4l issue with 'live.remote~' unfortunately. the biggest hit is when parameter-seqs point to mixer elements for some reason - volumes, pans, sends, x-fader etc. sticking to device parameters will keep your cpu down.
updates soon, thanks for comments.
daren, this is even better than isotonik. really, congratulations. it feels like what m4l was intended for. simple but powerful, a device consisting of one great idea (!) that is more than the sum of its parts. nice one. (one day we will all be as good as hoffman!).
more info / opinion, thanks to Lemubara:
http://www.lemubaratools.es/2010/03/01/j-g-spectral-delay/
http://www.lemubaratools.es/2010/03/01/j-g-spectral-delay/
more info / opinion, thanks to Lemubara:
http://www.lemubaratools.es/2010/03/01/j-g-spectral-delay/
http://www.lemubaratools.es/2010/03/01/j-g-spectral-delay/
hi robduro.
technically it does not matter, but i keep all my devices organised as they are in live / mfl:
1. download from maxforlive.com
2. now move the '.amxd' file, called 'JG.SpectralDelay.amxd', TO your M4L AUDIO Effects folder. I.E. - [your Ableton Library]/Presets/Audio Effects/Max AUDIO Effect/...
3. Start Live and drop 'JG.SpectralDelay' into an AUDIO track... etc...
technically it does not matter, but i keep all my devices organised as they are in live / mfl:
1. download from maxforlive.com
2. now move the '.amxd' file, called 'JG.SpectralDelay.amxd', TO your M4L AUDIO Effects folder. I.E. - [your Ableton Library]/Presets/Audio Effects/Max AUDIO Effect/...
3. Start Live and drop 'JG.SpectralDelay' into an AUDIO track... etc...
from tim place (developer) on C74 site:
"
For building standalones...
audiounit~ uses the sqlite database extension to maintain the cache of scanned plug-ins. So you need to include the sqlite extension in your application bundle (look in Cycling '74/extensions).
"
http://cycling74.com/forums/topic.php?id=25316
i presume this means you have to freeze the 'sqlite.mxo', into the 'dependencies' of the device as well for mfl users to get it to work?
just a thought, two cents.
"
For building standalones...
audiounit~ uses the sqlite database extension to maintain the cache of scanned plug-ins. So you need to include the sqlite extension in your application bundle (look in Cycling '74/extensions).
"
http://cycling74.com/forums/topic.php?id=25316
i presume this means you have to freeze the 'sqlite.mxo', into the 'dependencies' of the device as well for mfl users to get it to work?
just a thought, two cents.
hi lek.
i'll do better documentation for the full 'version 1'. in the meantime...
an envelope follower 'listens' to an audio signal and translates that into usable data. in 'Anti-lope' that data can be sent to other effects parameters in your set to control them. therefore, as a very simple example, if i put a drum loop through it i can make this control the gain level of a utility device, so, every time the drum is 'loud' it will send the gain up loud, every time the drum loop is soft it will turn the drum utility gain down.
to best understand it it is worth trying this simple experiment: load an audio drum loop on to an audio track. then load a 'utility' device onto that track. then load 'Anti-lope' onto that track BEFORE THE 'UTILITY' DEVICE. then in 'simple mode' map the 'parameter' controller (using the menus) to the utility gain you loaded earlier. now play your drum loop. the crucial thing here is to play with the 4 controls - input: this is how much level you will send to the envelope following device / interval: this is how fast the follower will work (shorter times = faster) / sharp + smooth: these affect the shape of the envelope data - a bit like a compressor - sharp is the 'curve' effectively, smooth is like fade time.
if you play with these controls whilst attached to the utility gain you will immediately hear the differences - jumping or sliding the utility gain.
once you can do this, you can do anything else with this device.
hope that helps for now.
i'll do better documentation for the full 'version 1'. in the meantime...
an envelope follower 'listens' to an audio signal and translates that into usable data. in 'Anti-lope' that data can be sent to other effects parameters in your set to control them. therefore, as a very simple example, if i put a drum loop through it i can make this control the gain level of a utility device, so, every time the drum is 'loud' it will send the gain up loud, every time the drum loop is soft it will turn the drum utility gain down.
to best understand it it is worth trying this simple experiment: load an audio drum loop on to an audio track. then load a 'utility' device onto that track. then load 'Anti-lope' onto that track BEFORE THE 'UTILITY' DEVICE. then in 'simple mode' map the 'parameter' controller (using the menus) to the utility gain you loaded earlier. now play your drum loop. the crucial thing here is to play with the 4 controls - input: this is how much level you will send to the envelope following device / interval: this is how fast the follower will work (shorter times = faster) / sharp + smooth: these affect the shape of the envelope data - a bit like a compressor - sharp is the 'curve' effectively, smooth is like fade time.
if you play with these controls whilst attached to the utility gain you will immediately hear the differences - jumping or sliding the utility gain.
once you can do this, you can do anything else with this device.
hope that helps for now.
hi, pp again.
i guess i should not have replied so quickly to the above. back at my live computer, i just successfully used 'Anti-lope' 0.9 to control the 'Looper' button. i haven't really used looper much, but my oversight is embarrassing anyway! parameters are ready mapped with my system!
open a set. drop looper on one track and anti-lope on another. in the parameter control drop-down menus in anti-lope choose looper as the device and 'state' as the parameter.
the audio material you feed the anti-lope with is key, as are the anti-lope settings. i just successfully had a two bar drum loop turning the looper button between play and overdub on the kick downbeat no problems. the settings with a drum track feeding anti-lope should be high 'input' and 'sharp' values, low 'interval' and 'smooth' values - this gives short sharp bursts of energy to the parameter and the looper button triggers when there is a peak that reaches the top. some smallish scaling values pre-parameter helps of course.
hope that helps.
of course for more finesse and control (like simulating double-clicks on the looper button) you would have to roll your own OR feed it with some absolutely perfect audio material pre-designed with attacks in the right places i presume. Or make some very clever automations to 'Anti-lope' (very possible actually).
enjoy.
i guess i should not have replied so quickly to the above. back at my live computer, i just successfully used 'Anti-lope' 0.9 to control the 'Looper' button. i haven't really used looper much, but my oversight is embarrassing anyway! parameters are ready mapped with my system!
open a set. drop looper on one track and anti-lope on another. in the parameter control drop-down menus in anti-lope choose looper as the device and 'state' as the parameter.
the audio material you feed the anti-lope with is key, as are the anti-lope settings. i just successfully had a two bar drum loop turning the looper button between play and overdub on the kick downbeat no problems. the settings with a drum track feeding anti-lope should be high 'input' and 'sharp' values, low 'interval' and 'smooth' values - this gives short sharp bursts of energy to the parameter and the looper button triggers when there is a peak that reaches the top. some smallish scaling values pre-parameter helps of course.
hope that helps.
of course for more finesse and control (like simulating double-clicks on the looper button) you would have to roll your own OR feed it with some absolutely perfect audio material pre-designed with attacks in the right places i presume. Or make some very clever automations to 'Anti-lope' (very possible actually).
enjoy.
hi markemark29.
not a dumb question. and good point. and cool idea. the answer is... yes... i THINK so.
if i was doing this myself i would build a very simple m4l device with a live.slider that was enabled for parameter control from 'Anti-lope'. i would map this for 0. - 1. float operation, and on its output i would put a threshold control (for example, a [> 0.5] object). then i would map this flag (via [sel]) to send to the looper button. i presume that the looper button takes 127 as 'on', although i haven't checked (i'm away from my live computer at the moment), so [sel 0 1] bangs a 0 and a 127. ignore the 0? this needs to then go to your own parameter control so you can map it to the looper.
however, maybe it need not be that complex. maybe i can provide a "bang 127" output option on the next version for you. i'll see how it goes. i cannot provide midi out (that would be the simplest) because of the inherent limitations of audio devices in live.
anyone have any other ideas?
best.
not a dumb question. and good point. and cool idea. the answer is... yes... i THINK so.
if i was doing this myself i would build a very simple m4l device with a live.slider that was enabled for parameter control from 'Anti-lope'. i would map this for 0. - 1. float operation, and on its output i would put a threshold control (for example, a [> 0.5] object). then i would map this flag (via [sel]) to send to the looper button. i presume that the looper button takes 127 as 'on', although i haven't checked (i'm away from my live computer at the moment), so [sel 0 1] bangs a 0 and a 127. ignore the 0? this needs to then go to your own parameter control so you can map it to the looper.
however, maybe it need not be that complex. maybe i can provide a "bang 127" output option on the next version for you. i'll see how it goes. i cannot provide midi out (that would be the simplest) because of the inherent limitations of audio devices in live.
anyone have any other ideas?
best.
hi wetterberg, thanks.
to be honest i think i agree with you about the sample glitcher part - overkill maybe in this device. i am thinking of ditching it all together for 'version 1'. (would anyone mind?). i will do some general updates soon and see how it goes.
i just uploaded another parameter modulator here: http://www.maxforlive.com/library/device.php?id=251 ... if anyone is interested.
to be honest i think i agree with you about the sample glitcher part - overkill maybe in this device. i am thinking of ditching it all together for 'version 1'. (would anyone mind?). i will do some general updates soon and see how it goes.
i just uploaded another parameter modulator here: http://www.maxforlive.com/library/device.php?id=251 ... if anyone is interested.
hi rozzer, great work, and thanks. a point though - all the automation / modulation appears under unusable generic object names (like live.numbox[1] etc). could you look into naming all your parameters etc with rozzer-type names and ordering them? my names suck, (and i do hate to use edits of others devices, (!)). thanks again!
hey prebentious, you keep coming up with these crazy little devices which are, quite simply, awesome good cool ideas. wtf?! where the ideas come from?!...
pp here:
ok everyone --- download version 1.4... it actually... WORKS, all of the time. sorry about that. seems i was having troubles with the way m4l reads pfft~s inside of poly~s, and some other silly stuff that happens when freezing / etc.
again, sorry. enjoy. and please feel free to feedback on usage / bugs etc...
ok everyone --- download version 1.4... it actually... WORKS, all of the time. sorry about that. seems i was having troubles with the way m4l reads pfft~s inside of poly~s, and some other silly stuff that happens when freezing / etc.
again, sorry. enjoy. and please feel free to feedback on usage / bugs etc...
oh dear, humble apologies - i was trying to add too much too quick, very annoying of me. however @AuralBee (+others?), is it the "1.1" version you have? - that was the stupid version i screwed up and it lasted a few hours. version 1.2 should fix the 'no sound' issue and other things. please confirm / let me know. it is working here, but i will take another look and report back...
pp here: i have now added an on/off switch to the preset gliding function. default at start-up is 'off'. this way you can decide whether or not to go for the full cpu spikes. this now works with mouse clicking and/or automation/modulation. also new random function, etc...
pp here: @AuralBee - glad you like it. to confirm - yes, my computer is so old and slow i cannot actually use the preset gliding 'live' without massive cpu jumps. this is why i intentionally chose to make the midi-automatable preset-selecting NOT go through the glide feature, but happen instantly. this is a limitation of the way the patch is coded - in a cpu intensive way. there are other ways to do all this. make sure you click on the "?" icon and read the help file - you will find web links to the original patch coder there, some links to other spectral delay examples and explanations of how to get around a couple of the limitations and why things are as they are. enjoy.
i THINK this might be a known 'maxforlive.com' problem. try switching web browser, to firefox or chrome or whatever. but if the file you download is called "BeatGenSeq-Mod.amxd.htm" then you can just delete the ".htm" off the end and it will work fine. any moere probs get in touch with 'maxforlive.com' i guess. hope this helps.
hi prebentious,
firstly, i just realised my first post must have sounded condescending. sorry, it was not supposed to be - just discursive and friendly is all. secondly, the counter issues - yes, mine does similar to yours - it is because we are TRANSLATING b.b.u into time, not actually counting real time.
much as i love it, live is a very na?ve and basic program, in that it believes the world only works in bars and beats. i DO find this really annoying. so, if you change time signature on the fly, the 'bars beats units' readjust, as if the whole set had been in the new time sig. likewise, if you change bpm on the fly, or automate it, the time adjusts, because it is translating rather than counting. i dream of the day live has a real timeline, esp. now m4l is part of the equation. in fact if live had real timeline and multichannel i would ditch my steinberg / digidesign crap in an instant. until then i need them.
on the 100 ms point, we will have to agree to disagree - that is an eternity of time to me, where lots of stuff can go wrong. i'll stick with my '@quantize 10ticks' thanks! ha!
[of course, if we hooked up a quantized 'phasor~' to a 'clocker' object we could have realtime, with a bit extra maths of course].
firstly, i just realised my first post must have sounded condescending. sorry, it was not supposed to be - just discursive and friendly is all. secondly, the counter issues - yes, mine does similar to yours - it is because we are TRANSLATING b.b.u into time, not actually counting real time.
much as i love it, live is a very na?ve and basic program, in that it believes the world only works in bars and beats. i DO find this really annoying. so, if you change time signature on the fly, the 'bars beats units' readjust, as if the whole set had been in the new time sig. likewise, if you change bpm on the fly, or automate it, the time adjusts, because it is translating rather than counting. i dream of the day live has a real timeline, esp. now m4l is part of the equation. in fact if live had real timeline and multichannel i would ditch my steinberg / digidesign crap in an instant. until then i need them.
on the 100 ms point, we will have to agree to disagree - that is an eternity of time to me, where lots of stuff can go wrong. i'll stick with my '@quantize 10ticks' thanks! ha!
[of course, if we hooked up a quantized 'phasor~' to a 'clocker' object we could have realtime, with a bit extra maths of course].
hi Prebentious, i like your counter a lot.
i THINK that the timing issues may be because your metro - and logic from it - is not exact enough? i built a stupid big counter (first thing i wanted from m4l - crazy! glaring omission from live!) and i use a "metro 10ticks @quantize 10ticks @autostart 1". there is also some clever useful logic in the max5 "Global Transport" as well. it is in the 'extras' menu, right click the floating window to choose edit, then click 'explore'.
let me know if you wanna see my counter - nowhere near as pretty and functional as yours as i tired to do too much with it.
i THINK that the timing issues may be because your metro - and logic from it - is not exact enough? i built a stupid big counter (first thing i wanted from m4l - crazy! glaring omission from live!) and i use a "metro 10ticks @quantize 10ticks @autostart 1". there is also some clever useful logic in the max5 "Global Transport" as well. it is in the 'extras' menu, right click the floating window to choose edit, then click 'explore'.
let me know if you wanna see my counter - nowhere near as pretty and functional as yours as i tired to do too much with it.
i did agree with you at the time you posted, but just to say:
i recently started using this again for something and it seems solid and working well in Live 8.2.2 & Max 5.1.8. so obviously something good happened behind the scenes.
digging into it there are things i would like to change / update though, so hopefully i'll be able to do that very soon.
pp