GRM Tools – DYCP Week 6

In all, GRM Tools (the complete set) are a really straightforward bunch of programmes that do sometimes weird and wacky things purely for the sake of the weird and the wacky. I get the impression that any aesthetically pleasing (to my ears, anyway) sound that’s produced is secondary to the intellectual process of the maths of the Tools themselves. Or there’s a halfway balance between the two.

It’s also come to my attention that my journal notes can fixate on the quality or nuance of the manual’s prose rather than the program I’m learning by following it. I’ve come to appreciate the skill and art of writing a manual – how it’s structured for both reference and tuition, how it’s set up for both beginner and advanced levels, and how the personality of the writer comes through – their philosophical bent and sense of humour. In the case of GRM Tools, I wonder what Gallic gems might have been lost in the translation from French.

I’m developing a philosophy of customisation also. As I move through all of these programs on the course, I can see how well the implementation of the opportunity for customisation has been set up. I see the spectrum, from beginner-to-easy selection of options (say, a square wave vs a sine) to the advanced-hacker level – the point at which you have to understand the code rather than just cut-and-paste; the level at which you use the tool for something it was never designed for (even though it, perhaps, ought to have been); and everything in between.

Customisation lies somewhere in the middle. It’s not beginner, it’s not easy; but it’s not ‘hacker’-level either. It’s built-in, but it’s optional. It requires some investment of time, a level of inquisition and curiosity, a willingness to experiment and envision ‘what if…’.

Anyway.

I enjoyed working with GRM Tools. They’re simple but powerful and sometimes make surprisingly beautiful sounds.


Journal

18/1/22

I’m plodding through the manuals for extra snippets of information that aren’t obvious from any of the Tools’ interfaces. The interfaces are simple and straightforward in design but, although there’s little that’s new to discover, there are always one or two little extra functions that I missed by just playing around with them.

As I was ploughing through though, this sentence caught my eye:

“In the centre, the source stops, and the travel time is infinite.”

From the GRM Tools Space Manual PDF

Out of context, what a lovely bit of philosophy…

Manual’s finished. All possible information gleaned. Made a few interesting ambiences – I think that’s what they may be most useful for in later months: getting random sounds recorded or some raw stuff from instrumentalists then hashing that through these tools in a chain – and possibly post some Reaktor processing.

Towards the end of the day I was getting a bit braindead so went into messing-around mode and spent a bit more time specifically with plugins Evolution and SpaceGrain, using audio I’d produced last week and last month.

These are all very atmospheric, ambient and soundscape-y so I reckon I’d likely end up using them as raw materials too and layering over some solo instrumentation to draw out some of the suggested melodic and harmonic patterns. In this way, I’d use what came out of these random sounds to hopefully spark inspiration.


17/1/22

Been thinking and writing a lot about the idea of customisation. As a sort of philosophy.

The idea that nothing in life comes ready-made for you (even things that claim to be), so you have to make customisations (whatever that means in the moment) to get whatever-it-is to work better, more appropriately – more tailored to your lived experience.

This feels like a deeper concept that’s maybe embedded in one of my core beliefs. The need to understand context and how something works, and then making little tweaks or bigger modifications to fit with what is needed at the time.

Not as extreme as hacking; it’s not violent or without consent. There’s no gleeful, anarchistic, counterculture intent… customisation is more practical, perhaps. That the customisation is maybe expected and possibly even encouraged by the maker, but not a necessity in order to use whatever the maker made.

I’ve felt this sense of opportunity with each of the sound tools I’ve been investigating – that each tool is good enough already, but in order to get either the tool or the sounds I want to make from it, I have to go (at least a little) deeper to understand what’s happening behind-the-scenes, learn a bit more about the tool’s idiosyncrasies and strengths. 

Back to business. Going through GRM Tools manuals now to see if there’s anything I’ve missed or anything I’m fudging rather than actually understanding how it works.


12/1/22

Automation – Logic already sets up controller bindings from its automation dropdown, all labelled properly, hurray!

So that just means a bit of midi learning via the control panel or handy short cut ⌘L. Well that was easy.

Sooo… I can save a channel strip along with all the hardware controller bindings and label them in the track.

Does Logic save Track Note Pad notes in a Channel Strip?? There’s a thought. I’ve never bothered to use that before but it’d be useful for remembering which controller is bound to what without digging through the Controller Assignments page (because the latter is not particularly intuitive and never fun).

Let’s see…

The Track’s notes are NOT saved.

What about ‘Save as Performance’?

Hmm. Not saved there either.

Is it even possible to save notes or plain text with these controller assignment bindings?

(As an aside, I now understand what the point of a ‘Performance’ setting is – the ‘channel strip’ is saved with a program change binding so you can switch to it ad hoc during a(n actual live) performance. This is not useful information to me but it’s still nice to know.)

(As another aside I really ought to make better use of saving channel strips as sub-templates for ensemble patches especially as you can save auxiliary channels within the main channel strip.)

Maybe I should be saving these GRM Tools chains as a ‘Patch’, so it can be applied to a channel strip that already has regions on it, rather than a channel strip in and of itself…

Yes, this is a good course of action. But does it save bindings?

Hang on though – any external controller bindings I set up will be part of the Controller Assignment preferences file! Ugh. So they aren’t saved with the channel strip or patch or whatever.

But it does mean that if it applies to one track it should apply to all? So can I apply a binding from one external controller to numerous different internal midi inputs (if I’ve even worded that right I really don’t know any more. But it’s better than saying ‘moving this thing makes that other thing move so the sound will change when I want it to’ (title of my autobiography) so it’s progress of sorts).

RIGHT ok so a ‘patch’ and a ‘performance’ are the SAME THING ok that makes things slightly less complex cool cool cool 😬

SO there’s no point in saving any text re external controller mappings because the mappings aren’t saved with the channel strip, they’re in a separate preferences file. I’m going to count that as (sort of) a problem solved.

Manual mapping is easy enough to set up and I suppose it’s probably better to map external controllers to the internal controls that I actually want to at the time since the number of external controls is fairly limited to the 8 knobs I’m not using for other macro controls on this baby Subzero MiniControl thing.

But I digress.

Let’s see about this ‘multiple bindings from one external controller’ then…

Soooo it looks like mappings remain the same for equivalent parameters from one different GRM Tools plugin to the next. The ‘Preset’ control binding works on any of the plugins because they all have a Preset parameter.

(This wasn’t supposed to be a Logic X fact finding mission but that’s how it’s turning out.)

The bindings from the external controller map to the control panel knob position. So the binding goes to the controller knob, not to the parameter. The parameter mapping is a second, separate binding, and can be changed without changing the external controller mapping. Which, actually, is pretty handy. The first internal control knob can now always be moved by the first external knob etc etc.

Because I clearly have too much time on my hands and I quite like dabbling in making demo videos:
https://youtu.be/p2XR9AKqH5s

Let’s see if we can control with LFOs as well as external controllers, because that would be extremely useful and also a lot of fun (the only two reasons for doing anything). 

This is how it’s done and it’s (surprisingly) fairly straightforward.

I’m routing the midi out of Logic and back in again via the IAC bus (a virtual external midi thing) so I would’ve thought you could do something similar in the environment tbh. Must look into…
Here’s how I did it:

I don’t know how to animate arrows and stuff. Whatevs.


11/1/22

Early finish on Logic’s Environment means an earlier start on GRM Tools than I’d scheduled. I don’t think I’ll need all the time I’ve booked for this either – certainly not 3 weeks. I vastly overestimated their complexity. I think midi automation and making chains of GRM plugins in saved channel strips may be a useful way to spend some of the time, going forward.