Jan 2016 - Noodling Patches (challenge/discussion)

#1

Challenger: @johannes

Challenge: noodles patches - self-playing improvisation patches

create a patch which plays on its own accord, and can be influenced/controlled by the user with 2 compositional controls, at top of patch, and clearly labelled

Submission window: Fri 29th 00:00 - Sun 31st Jan 23:59 (CET)

Submissions now open - on this thread

Voting window: Mon 1st - Fri 5th Feb 23:59 (CET)

Constraints:

  • maximum 2 parameters for real time composition control.
  • single patch file (axp)

Voting Criteria:

  • Awesomeness
  • More awesomeness
  • Patch clarity (is it still possible to see how the patch works?)

Hints/Suggestions:

  • use patch/patcher for polyphony rather than axs (due to single file constraint)
  • you can use firmware samples for percussion, but no external samples (due to single file constraint)
  • the constraint is on compositional control, other controls can be included for sounds etc
Jan 2016 - Noodling Patches (Submissions/Voting)
#2

How are people getting on?

I've spent some time on this ... 2 parameters is quite a challenge :smile:

#3

I got something, but have the opposite problem. Trying to figure out what the 2 controls actually effect. :grinning:

#4

he he... yeah, so many choices...

Im assuming in addition to the 2 parameters ( plus a gain control) , and then the 8 presets (to allow for some variation in the multitude of other things that could be tweaked)

of course then the user is free to tweak whatever else they want, but thats 'on their own head' :smile:

its a lot of fun, definitely would recommend people have a go, quick n simple or complex monster - its a fun game.
and Im certainly learning a few things from it. it will also be fascinating to see peoples patching approach/techniques, I'm sure lots to learn from there too,

#5

I'm having great fun with this contest :smile:
Can we submit as many patches as we want ?
I'm on my 4th patch (and more to come), and I will have a problem selecting the one I like the most.
As there is nothing to win (apart from pride), I think we should be able to submit as many as we want.
What do you all think ?

Other small question : what limits you most while making patches?
For me it's not the CPU, I'm always limited by the 'SRAM' overflow. (too many reverbs, delays and things)
I wouldn't mind a SRAM meter in the patcher either.

#6

good question, what do others think?
personal view, i can't see any issue.... unless we start getting a huge number of entries, when it might be a pain during the voting process. but for now Id say the more the merrier :smile:

time.... but apart from that, I guess it depends cpu if doing large number of voices, sram if not...
(i do try to keep it in check as i go along)

sram, make sure if you are doing lots of subpatches to zero out presets/modulation sources unless you are using them, they can consume alot of memory... which you may not need

SRAM meter, I think thats a bit tricky, I think, we only know when we compile and link the patch... so we would have to be background compiling to do this, which would have cpu load... and the have to interpret the errors. could be possible in the future (optional in case you are using a slow computer) .. the issue though is this can only say when it fails.
hmm, unless we perhaps read the elf file? ... hmm perhaps that could work, if we report each time to went live... then at least as you iterate through development you would see it grow...

alternatively I guess we could guesstimate, by looking at the sizes of objects... and knowing the constant overheads e.g. parameter maps... but probably hard work, and not very precice.

#7

I had a really cool idea, however i have found it rather difficult to implement: some "darwinian" random pattern generator.

The pattern creation would be divided in discrete steps (or generations), in which some amount of randomness is introduced: for each step the user has to decide with two buttons if the generation survives or dies. If the generation survives the amount of randomness in the parameters is reduced, otherwise is slightly increased.

A more clever way to approach this could be to introduce branching, however that's far too difficult to do just by patching.

In the end i switched to some other kind of randomness, and we'll see how it goes :grin:

#8

Ok, today is the opening submission day, shall we start a "submission only" thread (each month), and keep this one for gossip ?

#9

a good idea, Ive been away for a few days, just got back ... so will do in the next couple of hours, if someone hasn't beaten me to it :smile:

EDIT: ok, open...

submissions will close, as soon as I get chance on monday morning to create a poll, so you may get an couple of hours extra. (Im not sure if I can close the topic, and still allow voting, if I can thats what will happen)

#10

@mtyas , just been going through your patches ... nice stuff, some really nice textures... fascinating. definitely need a bit more time with them, as feel I've just scratched the surface :smile:

one has a small issue, underthedome.axp, looks like it contains a custom object, so is not running.

#11

Thanks !
I can't seem to find the custom object used on underthedome that could cause a problem, can you give me more info ?

#12

its osc/phasor compl GC in patcher/patcher_1

(tip: I temporarily 'disable' custom search paths, by putting a # in front of the patch I want to disable)

#13

Ok, I've found what I did, I first used a Bass Drum sample, and then changed it by putting the Bass Drum module created by @JSZ (Sorry for not mentioning it before, or in the patch, I forgot about it or probably wanted to change it, and forgot). Anyway, he uses @alexk version of the phasor object, that has a reset inlet (you can find it here : in this post .
I might change the patch if I have time tomorrow, otherwise you can probably just use a normal phasor object. I'll probably do what I wanted to do anyway, now I think about it :smile:

Thanks for debugging anyway, and it's quite an investigation to find some of the things we copy/paste into our patches

#15