User Details

Username: pishposh86
Website: None provided
Facebook: None provided
Twitter: None provided
Soundcloud: None provided
Account Status: enabled
Member since: Mar 06 2011
About pishposh86:
(report this profile)

Devices by pishposh86

No devices have been posted by this user.


Comments by pishposh86

Comments

Jesus man, I make a comment on one device, then go to the next one in your library and just get, "Ohhhhkay, mind has been read even MORE this time". The one thing that's great about live and especially m4l is seeing how vastly different some people's performance setups are...however I'b bet that you and I probably are trying to achieve very similar things, with respect to control-signal routing.

I see a lot of potential for this, thanks. Hey, if you get a chance, email me at ryan.e.dunlap@gmail.com. You're obviously performance-oriented and if you're interested, I wanted to share a text file I put together containing ClyphX code for a grid of clips.

Long story short, what this accomplished is making any grid controller, let's say a launchpad (in note mode, with a grid of buttons midi-mapped to trigger the aforementioned grid of clips) serve the purpose of being a seamless (and I mean SEAMLESS, no break in audio whatsoever) switch between the sends in a track, granted you have a performance setup where you have a considerable amount of returns that you want to be able to, at the touch of a button, jump between sends without, again, a break in the audio.

Since you're controller's columns are mapped to the columns of clips (which each represent a "dominant" switch for a send on the track that column is controlling), you have visual feedback of what send your track is running through.

The code works as follows, lets take a column of clips controlling sends A,B,C,D on track 1.

Launching clip A (corresponding to send A, which in my case is my dry through, and we'll call S-A) executes ClyphX code that all at once switches S-A from 0-127, S-B from 0 - 0, S-C from 0 - 0, S-D from 0 - 0.

Launching clip B switches S-A from 0 - 0, S-B from 0-127, S-C from 0 - 0, S-D from 0 - 0...

...and so on, clip C sends A-0, B-0, C-127, D-0, yadda-yadda.

My workaround before was midi mapping a controller I made in MIDItouch, only because it let you send multiple CC's from one control, which got directly MIDI-mapped to the sends. It WAS a seamless transition (though very rarely a small, but audible click), but even tethered through USB using MyWi, there was sometimes latency issues from the controller.

Again, this is instantaneous, and given you don't have eight tracks and eight effect returns, you have pads left over on your controller for the signal path routing within those returns. Ha, now that I've gone and explained it anyway, I guess email me if you want the text file template I made of code (enough for one column of I think 6 sends) that allows you to just do a find and replace of a character (I think I chose X) in the whole document, so you can just repeat for each track that is going to have it's sends mapped to a grid-controller. Let me know, man.

Holy fucking shit, you...I had a dream a few years ago about this type of thing, and then createdit the next evening with some m4l stuff and 3rd party plugins, except it was three assignable envelope followers that were each set to monitor a band that the source signal was divided into - Lo-Mid-Hi. It was fantastic for some synth-perc patches I made in Sunrizer (if you have an ipad, you surely know about it), that were basically sequenced with an arpeggiator and LFO, with the noise generator key-synced as to easily dial in "HH" portions by note. The whole point is that this material was perfect for this idea because, with the benefit of any ramped LFO waveform that was partially driving the sequence, you'd have some portions of the rhythm sliding between the BD and HH that had a freq gradient which straddled the crossover between the bands the env-followers were monitoring. Assigning the envelopes to parameters on spectral effects like vocoders really got some neat results. Sorry for the rant, I'm just really excited you did this; I will predictably say of course that you should absolutely take this idea further :)

This is a great release, and once again highlights the benefit of pseudo-open-source instrument architecture (that Live lacked pre-m4l): that user-designed devices are superior to factory devices. This, as far as the music I make is concerned, blows away the kick synths that come with m4l.

However, I stopped using it because of the inability to save presets or have Live preserve the parameters in a saved set.

The only workaround I used for a bit was to "static-automate" every parameter that isn't loaded with the device already, and even then it's a headache to adjust from then on if need be, as I'm sure you can imagine.

Can you PLEASE try to work out the saving issue? I am extremely grateful you've shared this with all of us, and would gladly pay for this device if you could fix this problem.

Thanks so much, either way.

Hey Naetron, it's Redun :) Just downloaded it and recognized your name. I'm very impressed with this, man.

By the way, I was wondering if you've made or know where I can find a device to use an envelope follower triggered by incoming audio to control any parameter in live, namely on 3rd-party AU's. Basically almost identical to LineFO and all the other similar stuff kicking about here.

I know someone's probably already posted one, I just can't find it.

Thanks a lot man, and again, great job on this one!

Ugh, sounds amazing. Simple and elegant, too, so it's definitely replacing some of the CPU-intensive BD-synths I rely on in Reaktor. Thanks much!