[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Date Index][Thread Index][Author Index]

Re: Jeff's scratching - a pseudo VHDL code


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

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

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.


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 
> 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 
>> 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 
>> be done:
>> -- I won't deal with variable declaration here
>> -- things we get externally: "controller", which is an integer 
>> the finger position, "finger", a boolean stating whether the finger is 
>> -- the controller or not, finally "clk", a clock for the process. 
>> 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 
>>        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.