The Thing I Like About Tracking

General Discussion
1

and the thing I like about a lot of tools that have small commands that can be chained together, is that with a bit of elbow grease and creativity, you can get effects that you wouldn’t otherwise be able to.

Case in point -

I was thinking about scratching, and what it actually is.
You are hanging on a waveform, speeding it up, slowing it down, reversing it, and cutting the volume on and off rythmically.

So, with a liberal combination of 02xx, 01xx, 0B00, 0B01, and the volume channel 40 / 00 ,I was able to “scratch,” and get the correct sound.

Granted, you need a high resolution to do this correctly (I was writing at 320/speed 3, as I generally do), but it still works and it still sounds RIGHT.

I believe this is the direction that trackers should go - small tools that let you get the expressions out that you want to.

2

http://desol8isol8.ath.cx:7331/~murphy/pro…0-%20imtoyv.mp3

that’s the track I did the scratching in.

it’s towards the end.

3

Not bad, not bad at all. :)

4

Yeah! Thats pretty sweet! :o

5

great stuff,

one thing I like, other then the 202 101 etc commands is the simple note off 'caps lock thingy when programming beats. This manual gating really helps emphasising groove in a pattern. There should be many more commands!

6

yes! I agree! I like the hard “off” when writing some breaks, and the soft “off” at other points.

More ways of manipulating wavs would be excellent, though I can’t think of many more besides what we already have. Maybe finer grain (FFF instead of FF) or an additional field to say “go to this value to this value over this amount of steps,” but that may get things to be a bit confusing.

I keep on finding myself wanting to have a “/” command to find instances of an instrument I’ve used once or twice, or ways of switching lines, etc. Again, I’m so used to coding with VI, I find myself wanting similar commands in Renoise. ;)

Also - Louis, I see your influences include “HIV+” - do you mean the french noise band or the death metal tracker band? If you mean the latter, those three guys are my good friends here in town, and I’d love to tell them they’ve influenced someone. :)

7

Haha, man that’s awesome!!!

Sounds just like real scratching :lol:

Gonna try this as soon as i get home :)

8

also check out toast.rns in this thread. very impresive. :walkman:

9

I think in the next 1.6 release they should include a scratching tutorial with the demo songs much like they have the tutorials for offset and gliding…

10

ok, since we’re sharing our scratching here :) I have a remix track up my myspace site called : Od year 3000 remix

where at 2.09 theres a scratch section, tho I didn’t use the backwards command, just 202 & 101 on looped scratch bits
http://www.myspace.com/plugexpert

(btw the only new cool commands I can think off, would be something to control the left & right loop markers in samples)

11

I’ve been thinking about the finer resolution thing and may have a solution, but since I don’t know all of the pattern effect commands off the top of my head, I can only speak in generalities.

NOTE: I’m probably using #'s already taken. Assuming that there are some free ones available and preferably adjacent to one another, then my idea will work.

Set up an additional say, 4 more groups of 00-ff offsets in series so that you have:

10xx
11xx
12xx
13xx

11xx would pick up where 10ff leaves off, with 13ff being your last point, giving you a total of 1024 points to start from rather than 256.

You could still use 09xx if a lower resolution suffices.

edit by It-Alien: removed guest post

12

the things i most like about tracking is the theories an principles.

just the way i was able to merge some of my old hardware ideas, into these principles.

i have come to think of samples as streams of sound, (which is of course exactly what they are) but the level of control over these streams of data is what is so appealing. with out the 2 dimensional views of the waveforms, this makes you precieve sound in exactly the correct way… as sound!
(an not some primitive 2d representation)

i also like the sound modeling aspect of it, instead of just sequencing like with all the candy coated bloated packages. the level of direct access to the data, gives the rise to synthesizing new inventions of sound, sound creating techniques, theories an principles. an alias to the most powerful synthes.

its the ability we have to put these theories into action, an thats why i indeed love tracking.

btw mr sensi did a pretty nicce apache scratch about 6 months ago, i would share it but since its not mine i cant justify doing that <_<

13

I just removed the doubled post which yank_crime has written because he forgot to log in

14

There are not much command prefixes left to use and spending 4 of them just for one function right away is pretty much a large waste.

The suggestion to define 256 precise offset points for each sample and attach this offset data to a slot being called by the 09xx command, seems like a much better solution and doesn’t require any new command.

I haven’t seen anyone cutting up drumloops in more than a few blocks of 10 snippets and people are probably too lazy to cut them up in more than 256 small snippets. It’s easier to click on a “Add offset” button and drag the node to any point in the sample you desire to have that offset.

15

“I haven’t seen anyone cutting up drumloops in more than a few blocks of 10 snippets and people are probably too lazy to cut them up in more than 256 small snippets.”

t’ would be cool tho for experimentation purposes, getting nitty gritty with the sample grains,…like a higher resolution form of granular synthesis. Especially at high speeds, inputting different samples after one other, changing offsets. It’s this kind of stuff that I’d like to see trackers develop in further.
whatever :)

16

that could go even further,[u]

rclick on the selection,
(in the sample ed.)
would copy the (begining an ending)
pointer offset data values to clipboard.

then go to the pattern editor, select a block,
rclick the selection an fill.[/u]
(using the Rclick menu; submenu, modifier and
advanced edit area for interpolation.)
i think that would speed up a few things.

only problem is. wouldnt keeping that as 09xx totally f’up timestretches?

there is No Doubt that the majority of us
want both finer res. and controllable loopoints.

so anyone have any thoughts about how these 2 could be combined?

17

oh yeah!! this just came to mind.
Must go slightlly Offtopic for a second.
i realized how much this would have helped me in the past.

instead of having a fixed # of clipboard buffers
wouldnt it be better to make them dynamic??

each time you copy a block of data it would make a new clipboard entity, similar but much wiser to the already implemented function.
it could have a history, and an option somewhere for the amount of allocated memory.
once the alloted memory filled up it would just recycle.

simply map these to the horizontal # row requiring only 1 or 2 modifiers! B)

this could also be enhanced with a ‘smart copy’ & ‘smart paste’ method
in which you could copy the pointers from a whole sample
sectioned up into the dynamic clipboard buffers
(from just the instrument panel)
an be able to pick an choose which pieces of the buffers you want to paste!

this would also require a spaghetti paste strainer.(only paste to empty areas)

18

Seriously, I’ll say this again:

CHANGE THE RESOLUTION IN THE EFFECTS COLUMN TO FFF!!!

That way we can have 4096 points of resolution AND the ratios remain the same, which will make transferring current renoise projects over to a new version much easier (you just have to multiply all columns by F!).

Case in point:

A break that is chopped well will usually be 1 or two bars in 4/4.

That means there are 16 well defined points in the break already, so you just need to break the offset up into 16 pieces in order to get to these spots, and work with the in between points to get finer grains.

If you have FF, your first hit is at 00, second at 10, third at 20, etc.

so 00,10,20,30,40,50,60,70,80,90,A0,B0,C0,D0,E0,F0 are all the “important”
parts of the break, with the kicks generally on the even numbers and the snares or off hits on the odds.

If you have a resolution of FFF, then your “important parts” become -

000,100,200,300,400,500,600,700,800,900,A00,B00,C00,D00,E00,F00.

Exaclty the same idea, because it’s just division of numbers with a base of 16.

Adding things like user-definable breakpoints is, imho, just lazy because, what if I want to use all of the possible points in the break? There are definitely times where I iterate through an entire break over the course of a bar or several bars in order to get that drawn out “blur,” or, even, tap the break at the beginning of the measure to make sure it stays in time. If I had user-defined breakpoints, I wouldn’t be able to do this. I’d have to load up an entirely different copy of the sample; and what if this was a REALLY high quality break and was about 2-3 megs? That’s 2-3 megs in my RNS file that I don’t need!

And don’t talk to me about aliasing the sample, because that’s just a kludge.

A better solution would be to:

a) Allow the wave editor to be manipulated with the keyboard.
B) Allow the user to go to a point in the break and hit a keypress that copies the current position to the clipboard.

THEN they can paste this into the offset column.

As people become accustomed to this it will become extremely fast (a matter of 3 keypresses) and, of course, once you paste once, you can refer back to that point as to the value of the offset. Unless you suck at cutting breaks, you’ll notice that it will be, or will be close to, a whole number.

I am really opposed to these sorts of “advancements” in the tracker paradigm. I track because I want to be able to have a tool that lets me get my ideas across effectively; I don’t care if I have to learn a new way of doing things, so long as that new way is faster and compatible with the previous concepts I’ve learned.

Fruityloops completely lost me when they introduced shit like the “scratcher” and started adding “generators” and charging people for them.

A tracker is a tool that can function as a DAW.
It’s an Emacs, or a VI. It’s not for the faint of heart, but once you learn it, you’re much better off than someone using Pico or Visual Studio.

VI does not want to be Visual Studio and visa versa.

I sound angry! But I promise I’m not. :)

19

The general idea that I follow when programming and designing is that modular is better: stacking smaller, easily identifiable blocks into an order that makes sense and gets you what you want.

e.g.

If I am looking through a source tree and I want to find all of the instances of the word “Zombie” in all cpp files, I could do something like this:

  1. Go to windows explorer, select search to a whole shitload of button presses, deal with the dog, and then wait as it may or may not find what I’m looking for. Plus, it wouldn’t give me the line numbers that the word appears on, just what files it’s in.

  2. type in my xterm:
    find | xargs grep -ni “Zombie” *.cpp

This returns all the lines in all cpp files where the word “Zombie” appears.
It’s case insensitive, and it tells me which file and which line the instance occurs in.

Granted, the second one takes a bit of learning, but you can’t admit that it’s less efficient. Especially because the “find” command spits out all the contents of the directory tree, which allows you to do whatever you want with those contents; e.g. pipe them into a command that find has never heard about.

But this allows us more flexibility and creativity. If I wanted, I could pipe the results of the xargs … into a program that takes text as input and e-mails it to someone.

It is THAT sort of flexibility that is inherent in trackers and I would hate to see lost with a very specific way of doing things.

20

:blink:

if you were directing that toward me, i stand in front of my thoughts 100% (until i change my mind :D )

am i correct in thinking? that what your saying is that you would much rather be using a fleet of small ncurses type apps/modules, from the cmdline so you could then pipe them into one another?
i enjoy the possiblities of this idea of yours, not necessarily for renoise.

if that is correct, i could actually see someone do this.

you could then write shell scripts, to make the enviroment the way YOU want it!

thing about that is, either way, its already available, supercollider is only an apt-get away! it can also be used with emacs & vi.

actually, im begining to think i have completely misunderstood your post!
oh well :P