#2

Well I’m not sure hardware is a total guarantee for immediacy. The hardware modular often feels to me like what you describe. It’s probably not as extreme as with Max, but I often find myself to spend a lot of time until I can make something that satisfies me and then… when you unpatch it, it’s all gone, and it always feels like “I’ll never be able to make this again”… which can be a bit painful when you just made a patch you were really proud and happy about.
But I’m digressing.
How would I deal with it, or how do I deal with it. The key I think is focus. No matter the tools and instruments, we usually have too many of them. The key to being creative and actually seeing results is focusing on few of them. But that’s not enough, the more open ended a tool (like max) the more you probably have to find a focus on what really interests you about max, what kind of patches or instruments would really add to your music? I think the endless fiddling is mostly due to the fact that we get carries away by the “let’s see what happens if I do that” though, which is often key to discovering new things and coming up to new ideas. So I would not try to repress it, but if you have a focus, then you can indulge in these activities and then eventually get back on track again.
The big question is, what should the focus be? To me it’s having a project or some projects that I’m working on. Having a goal helps me a lot to focus on specific “problems” that I have to solve, and reduces the random exploration of limitless possibilities.
But I have to admit that it sometimes works, and sometimes not. Depends on how tired and stressed out I am. :slight_smile:

5 Likes
#3

i force myself to
1/ develop software patches that are incrementally useful;
by that i mean that after a few hours programming, i should be able to use the result in music making. Of course it’s not always possible, but i find it helps to make sense of the long time and learning that can happen between an idea and its full realization. It also means that if i abandon my project for a few weeks, it is left in state where it is easier to pick up.

2/ attain a certain amount of publishable music.
This means splitting time between programming and actually making music.
I often give myself a set of rules; like allowing myself to use this or this “instrument”(patch, fx method, real instrument) that i know very well, for the basis of a piece of music; and resorting to exploring new things for the rest.
If in doubt for too long, i allow myself to fallback using “safe and productive” methods to complete the piece. In the end i will still have learnt something about my own process.

Public commitment, being through the Goals topic, or by working with someone/for something that has a deadline (be it a movie, an exhibition, a collaborative album, a creative contest…) helps a lot imho.

6 Likes
#4

Absolutely agree with that. Generally though, the return to hardware for people was precipitated by some desire to return to immediacy and tactility. You don’t have to look far to see that people continue to be fiddly with their hardware too though :slight_smile:

#5

I absolutely hear what you’re saying… and I also sometimes get lost in tinkering with both software and hardware (and studio setup, and mixing, etc…).

I try to make sure my tinkering is towards a desirable end. I try not to tinker just because I can’t think of anything else to do (or as procrastination), although sometimes I find myself doing that anyway. Some aimless wandering with your tech can open many new ideas and possibilities. The worst kind of tinkering is when you’re not learning anything.

Although I also try to be honest with myself about why I do this in the first place. I love music. I love sound art. I love technology. Fiddling with my computer back in the early 90’s is what led me to electronic music in the first place.

Regarding immediacy, I also gravitated back towards hardware (vs Max and PD that I was immersed in for 15 years) because I could plug it in and sound comes out. I could pay money for a highly functional module rather than spending hours trying build one in software that I would continually have to manage. It’s really nice, and in my experience leads to the more productive kind of tinkering.

However, I still go to software for certain things. I still use Max and PD lots while traveling and can’t have my hardware with me.

The difference in type of tinkering/fiddling might come down to something like this: with hardware I find I fiddle to get sounds, to make rhythms, to explore new ways of creating. With software I often found myself spending hours debugging an error in logic or general programming issue. That stuff can be fun and useful, but it’s not tinkering with sound… it’s tinkering with programming, even if sound is the end result. Sometimes I want to do one, something I want to do the other.

(this was a bit rambling…)

3 Likes
#6

perhaps we’re talking about this (I’m always talking to myself)…:slight_smile:

'There is a lot of folklore and legend associated with woodshedding. Bebop legend Charlie Parker, after his embarrassing attempts to solo at several Kansas City jam sessions, spent the entire summer of 1937 honing his technique while playing a resort gig in the Ozarks. He took all of Count Basie’s records, from which he learned all the Lester Young saxophone solos. At the end of this marathon woodshedding session, he reemerged as a mature player to be reckoned with.-P. Klemperer

and, ¿progress is an illusion :slight_smile:
“I do not wish to judge how far my efforts coincide with those of other philosophers. Indeed, what I have written here makes no claim to novelty in detail, and the reason why I give no sources is that it is a matter of indifference to me whether the thoughts that I have had have been anticipated by someone else.”

Ludwig Wittgenstein, Tractatus Logico-Philosophicus

it’s kinda wide open, no?


I mean, if we can record burning charcoal…(and make it sound great!)
then it’s up to us to say whatever it is we feel is important :slight_smile:

peace, this forum is great
image.jpeg3024×3024 1.55 MB

8 Likes
#7

It’s possible to regard Max in a similar way to using a hardware modular. Most of my patches consist mainly of a handful of BEAP modules geared towards a rather immediate result. Generally what I’m doing with Max, when I reflect on it, is sequencing MIDI. When I don’t feel like diving down the soft synth rabbit hole, or adding modular complexity (just want to get some music out of this sequence I’ve quickly patched up), I’ll send the MIDI to my Nord Rack 3. I regard these types of patches as ephemeral. They don’t get saved. The wires between my patchers no different from 3.5mm cables in this case.

0 to music in a handful of minutes. Patching as a quick sketch using only high-level abstractions.

Now, patches like the BEAP patches are really pretty complex high-level abstractions. Stretta put quite a bit of time into each one, I’m sure. But they’re reusable. The promise of Max to me is the ability to create new modules at zero material cost. That’s really a pretty remarkable promise! Once you’ve got your new bpatchers, you can re-use them endlessly in the ephemeral way described above.

I’ve just separated the experience of playing with bpatchers, and creating them. One is music-making, the other amounts to programming. Different tasks, different mindsets, different set and setting, different points in time.

Olivier of Mutable Streams mentioned in his Reddit AMA that he doesn’t put any Mutable modules in his rack at home because it would mean that musical sessions would descend into edge case debugging sessions.

So you’ve gotta compartmentalize.

And when you are programming, well, you start to ask a different set of questions. Am I using my time as efficiently as possible while programming? This is how threads like

get started.

Some of that thread appears to be pushing towards programming languages based in text, that drop to a lower-level of abstraction. Ugh. That sounds even further away from music-making! And it is. But the idea is not to stay at that low level of abstraction. The idea is to get good at working at that low level in a structured manner, so that you can create high-level abstractions that are more thoroughly your own. Where the jacks and the wires are all in the right places, carrying the voltages and signals that you really need, out of abstractions that are deeply understood by you, in a form that is maintainable and reliable over long periods of time, with less vulnerability to the whims of the platform changing under your feet. In other words, much less ephemeral programming.

So that when you are making your ephemeral music (striking while the iron of inspiration is hot!) you don’t get pulled into a session of debugging your less ephemeral high level abstractions.

Or there are some that say what you need is to work with higher-level abstractions. Rather than opening up your IDE and writing C or JavaScript code, open up Reaktor and work with decidedly musical abstractions. “Climbing the ladder of abstraction” is a task that every programmer seems to approach in a slightly different way.

http://worrydream.com/LadderOfAbstraction/

This process of taking off a musician hat and putting on a programmer hat works in other ways. I find when I am working with synths I get really focused on certain musical qualities. Lots of attention gets placed on timbre. Some on rhythm. But my music theory thinking can get a bit flabby or even non-existant at times, especially on the eurorack modular. But put a guitar in my hands, and I start thinking about modes and progressions… Put a drum in my hands and I notice how much more prominent in my mind issues of metre and rhythm become… 88 polyphonic keys and the bleeps and bloops start to sound a bit more jazzy… so there are a lot of hats one could wear. You look pretty silly trying to wear more than one at a time.

But just as in school, one can only sign up for so many electives before you start to get spread thin. The hardest thing for me to accept is the fact that I’m really not likely to live for 200 years.

10 Likes
#8

I also think this frustration with “I started programming to achieve a goal and now I’m programming instead of achieving my goal” is the sort of frustration we all feel anytime we start to emerge from the rush of learning as a novice to the grind of learning as a journeyman. When the rapid revelations of plonking around as an extreme beginner give way to the slow and deliberate burn of practice and learning.

10 Likes
#9

Loving the responses. There are other ways to think about this as well.

For example, in a recent interview with Autechre (https://www.residentadvisor.net/features/2756) they talk about seeing themselves now as programmers more than musicians… they’re programmers making music. And, IMO, judging by the results it’s a successful model for them.

Their recent process sounds a lot like what @jasonw22 is describing. They spend a lot of time programming modules based on idea they have, then they shift to spending time combining those modules and seeing if they like the results. When they like the results it gets recorded.

It’s not that different than how I approach modular synthesis in general, really. It’s just a different ratio of buy vs build for the individual modules. And with that comes different amounts of debugging/just trying to get it to work.

1 Like
#10

My current hypothesis is the key to establishing iterative workflow & not totally losing oneself in programming is to be absolutely strict about playing music for an hour or so every day. Don’t understand why this is, but it seems to be an empirical fact…

For my Hammond Organ practice I’ve reduced this activity to an automatic, mechanical regime. So even when too tired from work or whatever to feel remotely inspired (which is most days to be honest) - there’s no moment of ‘what the heck do I play?’. I just play all the pieces I’ve learnt, maybe work on a new piece if I’m feeling good, then occasionally run some scales if feeling really braindead.

The aspect I’m struggling with is how to structure a ‘practice session’ for the more esoteric performance practices I’ve discovered through engagement with lines/monome community. Currently I only really play around with this stuff when really get the urge, which feels like not enough of the time to make progress.

Thinking about developing an experimental notation system(s), just for myself. Mostly to define particular pieces and work towards a healthy practice regime like I have for the Hammond…

2 Likes
#11

I can tell you what @Rodrigo did (and maybe he’ll chime in too): he did away with the distinction. And not that he ever worried, but with the distinction gone the worry about balance isn’t even a thing to consider. Kind of like how a flat line has a slope of 0, but a perfectly vertical line has an undefined slope.

I guess the questions are:

  • Do you preference one over the other?
  • Why?
  • Are these motivations external factors (like gaining status or leave historical artefacts…or etc) or internal factors (like self-improvement and/or self-indulgence…or etc)?
  • Also, what’s so great about balance (all things in moderation is the reverberation of the ancient Roman lifestyle…maybe the 21st century individual can/should go off the rails)?
11 Likes
#12

Would love to have a long talk about this sometime. I’m kinda with the idea that a diverse mind is a resilient one in terms of philosophy of life, but on the other hand, there are seasons. Seasons within a day, seasons within a year, seasons within a life. Varying your focus isn’t something you have to do “all at once”. It’s OK to specialize in a moment, and shift your focus in another. This is how I approach “everything in moderation”. The trick is to avoid having every little thing distract from every other little thing, by giving each thing its full attention in its time and place.

So much easier said than done!

4 Likes
#13

I’m not sure I did it in a conscious way but I have certainly done away with the distinction too.
I get as much out of the stuff that is related but doesn’t directly result in music being created (whether it be trying things out in Max or deciding that I really have to rearrange my room) as I do finishing a track.

4 Likes
#14

History of Sexuality vol. 2: The Use of Pleasure* (where Foucault describes the Roman “style of living” [which free men practiced/believed and was self-imposed])

The concept of things occurring in their time and place especially drawing an analogy to seasons is discussed in the chapter called Dietetics. He discusses them with relation to sexual practices but it’s a core set of principles that extended to every part of life.

In chapter 2 “The Moral Problematization of Pleasures” he lays the groundwork with these three parameters* from which everything had to be considered:

  1. Strategy of need: is it natural. If so it is accepted.
  2. Strategy of timeliness: “at the right time and in the right amount”
  3. Strategy of status: act in accordance with your place in society

based on the concepts of
Enkratia - the right mean between insensitivity and excess
and Sophrosyne - the superiority of reason over desire

“If you pay attention, you can feel Rome fall 9 times an hour” -McKenna (re time wave zero)

*edits

3 Likes
#15

[quote=“sellanraa, post:1, topic:7131”]
The problem is that the music-making is back to feeling less immediate. There’s the investment of time without seeing the ‘reward’.[/quote]

So what’s the “reward” in this context?
And would you say this (im)balance is specific to programming?
Surely the same could be said for learning an (acoustic) instrument, like in @abalone’s example above about Charlie Parker.

Yeah exactly. For me, and my practice in general (god I hate saying that, but it sums up what I mean here), any distinction at all is useless, especially when it comes to technical issues. I view programming as a part of the creative act itself, on multiple levels. For one, the poetic interpretation of the act itself being beautiful and engaging (which I completely believe), but in addition it is also performance, in a slightly temporally displaced way. As in, decisions you make while programming are near-compositional decisions, which will manifest at some point, that point just happens to be in the future.

I guess for what I do, in specific, there are so many hats, that the idea of hats itself is meaningless (as @angela pointed out).

In general, I think there’s a tendency to look down on technical things (programming specifically) as something that’s in service of something else, whereas one wouldn’t necessarily draw the same conclusion when talking about practicing an acoustic instrument, or writing a song, or lyrics, etc… These can all be meandering ‘pointless’ activities, with very little reward (or at least a shitty time/reward ratio).

So in my opinion, screw balance. Do what you want to do, no matter what it is (and hopefully it’s not investment banking!). Don’t worry if it’s useful, or meaningful, just do whatever it is. If it’s useful in something else, cool, if not, that’s cool too.

8 Likes
#16

Thanks for all the input/wisdom/insights. I really am glad I’m a part of such a thoughtful community.

4 Likes
#17

I’ve been thinking about all my creative output (music, design, art, programming, corporate consulting) as one body of work. When I evaluate how much effort I want to put into something I think about if I think it will add something to my body of work, practice, and/or knowledge. Is it something I will be happy to have done, for whatever reason? If so, I do it. Those reasons can be creative, financial, practical, learning oriented… anything really.

I love @Rodrigo’s questioning of “reward” as a concept… so important.

I also love @Angela’s and @sandy’s dissolution of boundaries between modes and acts.

Very inspired to work on something.

2 Likes
#18

Serious hat.

IMG_2220.JPG960×1280 243 KB

15 Likes
#19

https://mrpsmythopedia.wikispaces.com/Hercules

Am I the only one who sees the resemblance?

1 Like
#20

Fascinating subject, and one I ‘beat myself up over’ quite regularly.

Perhaps though this depends upon your background and intent.
Im a programmer by trade, and making music is a hobby with an intent to do something different, to explore a different side.

One side of me (the programming side) loves to have options, create options, build and make new things - but it, obviously, can distract/take free time away, from the act of making music. I also have a (guilty) feeling, that because programming is ‘easy’ for me (compared to music making) perhaps its a form of procrastination, spend time building instruments, rather than using them.

Its funny, I believe that programming (or any kind of tool making) is no less creative that music making, albeit, a different kind of creativity, a different kind of expression/exploration.
so I do wonder why the ‘guilt’?

is this due to society having this divide of engineering/art? tool maker vs tool user?
many instruments can be considered a work of art, so is a Luthier an artist?

I have at times considered ‘letting go’, does it really matter, if I just wander where my passions take me, perhaps its a cycle, once I’ve built what I want, I will sit down more comfortably with it - perhaps exploring music through the (technical) skills I have is the best way for me.

(but then again, perhaps thats my dark/programming side, just trying to justify itself ;))

thanks for the posts, its giving me a lot of food for thought.

5 Likes
#21

Just to be clear, I value the process and am not disrespecting (or at least not intending to) the programmer side of things, but I come from the other side as more of a musician and less of a programmer. So in many ways, the programming is a tool/vehicle to accomplish my goal of making music.

2 Likes