Support
Looper's Delight
|
Support |
|
|
Hi, I didn't know what VHDL is either, so I Googled it and became quite impressed! It stands for "Very High Speed Integrated Circuit Hardware Description Language" which is indeed a "hilarious" term, but also pretty self descriptive. What a smart system for a creative functionality designer (inventor) to pass over his ideas to an engineer that makes it happen in hardware and processes! I had no idea that modern tech gear originates from such simple mind tools. I like Rainer's idea that the processes only happen as long as you keep you finger on the plate (fader). Right from the top of my head I think that for looping I would like to use three more functions with this: 1) Option of a realign command generated by the "exit scratching". 2) Optional "latch mode" where the scratching is not repelling back to its initial state (of parameter values) but rather left at whatever parameter values you lift of your finger. 3) Option of a "musical quantize" mode, in which the pitch doesn't shift continuously but in musical steps. This could also be set to specific scales (from twelve tone scale to simple pentatonic... fixed micro tonal related to a root would be ultimately cool!). These three extras are not intended to mimic DJ mixer board scratching but to make it more performance friendly and versatile for live loopists. Ok, enough so far. As for the physical controlling I would rather use a touch sensitive XY axis floor/tabletop carpet than a DJ mixer imitation of some sort. Such a vector controller would not only permit linear moves, as the DJ mixer's fader, but also the option of jumping directly from one set of values to another - by lifting off your finger/toe and putting it down somewhere else (given the whole shebang can be run on "latch mode", see above). This vector control function would work fine with just a laptop's track pac as well. Another thing that Rainer's write-up brought up to me is the reverse playback idea. In my recent Mobius scratching setup I have never felt the need for reverse, since I'm already toggling reverse mode from a dedicated button. But when thinking about it, I bet it would really sound cool to slow down Rate until Reverse is automatically toggled at the slowest rate. Maybe a looper like Augustus Loop would be a better "engine" since it also allows continuous re-pitching? But that would mean you would have to set up the scripting in the host application. Mobius, on the other hand, already has this awesome built-in scripting and I personally think it sounds ok with the whole tone quantized re-pitching of Mobius (which is actually a very good thing when applied to other processes). Thinking about Jeff's post, on using MIDI CCx=64 as some mid point, I'm getting a feel that it could be possible for the user to script a sort of scratching with reverse included. As I understand his approach the value 64 should be the point where the Rate parameter reaches its lowest value. At the value 64 Reverse should also be toggled and as we go lower the Rate would increase again. As we go back from CC=0 the Rate becomes lower (sound slowing down and pitch falling) until we reach to 64 again and Reverse again gets toggled (now going into forward audio playback) and as we go higher above 64 the Rate increases (pitch and speed raising). However, I am missing one factor in this scenario: the values where Rate (pitch and speed) equals normal, i.e. the value where the loop is back at the same tempo and pitch as the original - even though it might probably not be in sync ;-)) Doesn't it seem logical to set those points at 96 for the Forward Playback half and at 32 for the Reverse Playback half of the total (MIDI CC# 0-127) parameter range? A final word: So far I have been "scratching" in Mobius by simply putting a loop into Multiply mode and then have a go at the Rate Shift MIDI CC# expression pedal (or my hand mixer fader assigned to the same processing) while playing new live audio. The audience then hears my live playing straight and the loop background being mangled by the rate shifting. On leaving Multiply Mode the loop plays back, but now the background straight and my former live playing being "scratched". I find this a very good performance technique. As for this idea about scratching with the reverse function we have to do it differently, as we can't catch the sound into a loop because if we do, all new live playing would be overdubbed at one point of the loop since the Forward and Reverse Playback directions tend to even out each other ;-)) A solution could be to record the sound of the scratching activities (maybe also plus the background?) into a new loop. This can be done by audio routing in the host application. Per On Sun, Aug 31, 2008 at 11:19 PM, Chris Gaber <fourstrng@yahoo.com> wrote: > I dont know whats going on here and I dont really care either, but that >is > hilarious. > On Aug 31, 2008, at 2:30 PM, Rainer Thelonius Balthasar Straschill wrote: > >> As an extension to my last message, here is some pseudo VHDL code >(that's >> because I'm not at all familiar what scripting language can do right >now - >> what's the status of the documentation?) to describe what I think needs >to >> be done: >> >> -- I won't deal with variable declaration here >> -- things we get externally: "controller", which is an integer >describing >> the finger position, "finger", a boolean stating whether the finger is >on >> -- the controller or not, finally "clk", a clock for the process. >There's >> a >> constant "clk_delta", which is the clock half-period in ms. >> -- >> >> process scratching is >> begin >> wait until finger'event and finger -- wait until you put a >> finger on the controller >> pause -- pauses >playback >> direction_s <= direction -- used to store playback >> direction (Forward or Backward) >> rate_s <= rate -- and rate >> ctrl_last <= controller -- store current finger >> position >> ctrl_last2 <= controller >> loop: scratching -- inner loop; >> active while finger is on the controller >> wait until clock'event >> if controller = ctrl_last AND controller = ctrl_last2 >> then >> pause -- pause playback >> if >> finger hasn't moved for last two clocks >> elsif controller != ctrl_last then >> play >> ctrl_delta = controller - ctrl_last >> if ctrl_delta > 0 then -- check for playing >> direction >> if direction_s = forward then >> forward >> else >> backward >> end if >> elsif >> if direction_s = forward then >> backward >> else >> forward >> end if >> end if >> pbspeed = ctrl_delta/clk_delta -- playback speed >> scale factor is the controller delta since last clk'event divided by >> clk_delta >> rate = ln(pbspeed)*17,3123404906676 -- ugly scale >> factor to convert from pbspeed to rate >> end if >> if not finger then >> exit scratching -- exit >> from >> loop >> end if >> end scratching loop >> -- if in the loop the finger is lifted, we resume here >> direction <= direction_s >> rate <= rate_s >> play >> end process scratching >> >> Hope that helps to explain what I'm after. Aaron, I'd also like to hear >> your >> comments if you'd like. >> > >