Thank you! The visual connection is something I really was looking forward to experiencing and @synthetivv brought that to life and much more!

Yes! I have been gently nudging Crow support to the top of @synthetivv’s backlog and he doubled down by suggesting JF support as well.

Any suggestions on how these would work would be appreciated. In the case of Crow I suggested that we map the 1/2 and 3/4 outputs to trig/cv from the stereo field in Euclidigons but we’re up to hearing other suggestions.

Thanks to you for the enthusiasm!

3 Likes

if you keep seeing this on Drifts/Barycenter drop a note on their respective threads & I’ll take a look.

FWIW I encountered the issue accessing Norns menu on Euclidigons with my Fates, but was able to work around it with quicker taps to K1.

Asides from that, a lovely script :slight_smile: well done!

1 Like

it was just the home button thing happening with those, but i figured it out. quick taps. sorry for the confusion

1 Like

Wow! I needed a little something tonight to settle down and this script is really doing it for me! I would love to see the polygon side count, size, speed, and position broken out as midi mappable! It would be so cool to move and shift the size of both shapes at once via cc’s.

The bouncing stereo field you can get when both shapes are nearly concentric and scaled large is amazing!

Oh! If crow output is coming, could the stereo image translate to 2 scaled pairs of triggers or envelopes?!?! Like shape one out be envelopes on outputs 1 and 2 whose amplitudes are scaled depending on their left/right position, likewise with shape 2 on 3 & 4?

2 Likes

Really glad it could serve that purpose for you – I’ve spent my fair share of time just zoning out while testing it. And I was really happy when I realized it made sense to pan the sounds based on the collisions’ locations on screen.

MIDI mapping is definitely a good idea, but I’m not sure (yet) what the best implementation would be. Params for “shape 1 size”, “shape 2 size”, etc. might be the most standard approach, but I think it could get confusing due to the way shapes can be dynamically added and removed: if you add a third shape, delete the first or second, and add another, does that reuse the params from the deleted shape? (i.e. is that now “the new shape #2”?) Or does it move on to “shape 4 size”, etc., and if the latter… when does it cycle back to #1?

Right now I think I’d rather have shapes listen on different MIDI channels – selectable from the main screen – to pre-set CC #s: say CC 8 (pan) controls position, CC 16 controls size, and so on. And you could assign all shapes to the same channel for macro control. Any opinions on that?

I like that Crow idea too – like @setfield said above, I’ve been imagining two monophonic pitch + trigger pairs, but providing 4x trigger or envelope outs would surely be useful too, and having the option to make them stereo pairs sounds really interesting. Do you have a specific patch in mind for that?

1 Like

MIND BLOWN! There can be more than 2 shapes!?! I was zoning so hard on 2 that I guess I didn’t dig any further.

Is far as a patch for 4 triggers (weird makenoise style triggers with amplitude variations) would be to ping 4 low pass filters to get stereo duophonic sounds or even quadraphonic pings. I have a couple of the mengqi dlpgs and enjoy panning their outputs across stereo space and pinging them with a bunch of triggers, some times with the same material passing through all 4 some times vastly different sounds.

3 Likes

oh, also:

  • MIDI out functionality is now merged into the main branch, so it’s available if you update via Maiden
  • There’s a new feature branch, keys (download here), that contains @dan_derks’s key layout and a new idea from @setfield that note/MIDI changes shouldn’t take effect until you release K3. I like it, so I’ll probably merge it soon unless anyone complains here.

@coreyr lol, yes! Extra glad it’s that much fun with just two. There can be up to 9.
and to your edit: pinging a pair of DPLPGs, yep, that makes a lot of sense. I’ll keep that use case in mind when I start work on a Crow mode.

6 Likes

May have found a bug? It appears that there is no hard limit on the octave range for shapes? Was noodling around after zoning for a good hour. 9 shapes, long attack and decay times (.3 sec and 1 sec), lots of reverb and some recordings playing back in tape. Gave encoder 3 a spin expecting it to cap at octave 8, kept on going right past 14 and promptly shut down all audio until sleeping my fates.

Ran through several variations, doesn’t seem to matter if its 2 or 9 shapes, short or long attack/decay times. As soon as I hit octave 9, it kills audio until restart.

Did not have my computer handy to check maiden.

2 Likes

actually going back to my original hypothesis in this armchair debug session. SVF cutoff is clamped to nyquist, but stability limit might be smaller. (weird though - looks like input should be clamped to midi 127 ~= 12khz, regardless of octave, and that should be alright.)

in any case it’s gotta be one of these ugens blowing up. next suspect is Comb.ar somehow.

2 Likes

why hello! Yeah, it’s gotta be hitting the Nyquist frequency somewhere. (and I did the same double take I think you must have done – there is indeed a note to myself that I should do a better job of clamping the note range, and I thought that must be the problem at first, but that’s before it gets fed to SC – all the engine.hz commands should be within the normal MIDI range.)

I hadn’t considered that Comb might be the source – I have no idea how it handles delays shorter than 1 sample, but on high notes, that could totally happen. The comb filter gets tuned to harmonics of the root note, sometimes very high ones. I’ll have to limit that.

edit: actually, I’m having a hard time reproducing this problem, and both in context on Norns and in an scide session, CombL and SVF seem to be surprisingly good at not blowing up at high frequencies. Comb gets a little weird when hit with DC, but then it recovers. I can also get the Norns reverb to cut out momentarily if I hit it with a ton of high frequencies, but it too comes right back once they’re gone. hmm. I thought maybe I could push a fix for this tonight, but I think I’m going to have to keep trying to break it before I can fix it…

1 Like

finally had some time to test this out with my OP-Z. lovely! Don’t know if this is possible, but could it have independent midi channels pr.shape? that would kick the op-z functionality into hyperdrive and enable you to do “full” compositions in the box.

1 Like

Should work that way already! multi (per shape) is the 17th option for the MIDI channel parameter. Then K1+E3 (or K3+E3 in the keys beta above) will set the selected shape’s channel instead of its octave.

(unless I’m misunderstanding — you’re talking about controlling the OP-Z from Norns, not the other way around, right?)

1 Like

you are correct in your assumptions! And I am in awe of this functionality!

2 Likes

Thanks for this. I had to update to the latest available firmware for this to work (200712). I am running the 200323 green PCB Norns Shield on a Pi 3b+ with F/W 200106 (that is what is referenced at https://github.com/monome/norns-shield) and I first got the “missing primitivestring” error, now after sleep / reset I just get “error: init” on the screen and the following in the Matron log:

# script load: /home/we/dust/code/euclidigons/euclidigons.lua
# cleanup
# script clear
including /home/we/dust/code/euclidigons/lib/shape.lua
including /home/we/dust/code/euclidigons/lib/midi.lua
pset >> write: /home/we/dust/data/system.pset
# script run
loading engine: PrimitiveString
Engine.register_commands; count: 14
___ engine commands ___
amp	 	f
attack	 	f
brightness	 	f
comb	 	f
env_type	 	i
gate	 	ii
hz	 	if
noise	 	f
pan	 	if
pos	 	if
release	 	f
trig	 	i
vel	 	if
wave	 	f
___ polls ___
amp_in_l
amp_in_r
amp_out_l
amp_out_r
cpu_avg
cpu_peak
pitch_in_l
pitch_in_r
# script init
### SCRIPT ERROR: init
/home/we/norns/lua/core/clock.lua:58: /home/we/dust/code/euclidigons/euclidigons.lua:433: attempt to call a nil value (field 'get_beat_sec')
stack traceback:
	/home/we/norns/lua/core/norns.lua:126: in function </home/we/norns/lua/core/norns.lua:126>
	[C]: in function 'error'
	/home/we/norns/lua/core/clock.lua:58: in function 'core/clock.resume'
	/home/we/norns/lua/core/clock.lua:23: in function 'core/clock.run'
	/home/we/dust/code/euclidigons/euclidigons.lua:431: in global 'init'
	/home/we/norns/lua/core/script.lua:82: in function 'core/script.init'
	[C]: in function 'xpcall'
	/home/we/norns/lua/core/norns.lua:127: in field 'try'
	/home/we/norns/lua/core/engine.lua:91: in function </home/we/norns/lua/core/engine.lua:89>
>> reading PMAP /home/we/dust/data/euclidigons/euclidigons.pmap

Hopefully this helps if anyone is having trouble getting this working. To update, I just went through system -> update.

2 Likes

Glad you were able to resolve that, and thanks for sharing the tip. I just edited the top post to say that Euclidigons needs version 200424 or higher of the Norns software (that’s when the coroutine-based clock system was introduced).

2 Likes

Really great script.

Just had a lot of fun with it: midi out to a synth making a droney melody / rythm with lower notes, then playing some higher pitched overlays while adjusting a filter.

A small feature request: it would be great to have the shapes parameters (position, shape, speed, note…) be saved in params so that pset save/load would allow restoring a previous session.

It is an essence a sequencer, it would be nice to be able to save and load those sequences.

3 Likes

Glad you’ve been using it. I’m up for adding this and will look into how others have done it to try to keep things standard-ish – do you have a script in mind whose behavior is close to what you’d like here?

1 Like

Update: I snuck in yesterday and merged the keys branch mentioned earlier into main. If you update from Maiden you might be confused for a moment, but found I definitely prefer @dan_derks’s key layout to the earlier K1-heavy one. I’ve updated the key descriptions in the original post.

Lately I’ve been working on a new branch that incorporates a “motion blur”-like effect for shapes that spin faster than can be conveyed by the framerate alone (where previously it might have looked like these shapes were spinning backwards), and adds guides at the bottom of the screen showing where/whether the currently selected shape is able to collide with others. Download here if you’re interested.

6 Likes

Do you have a demonstration of this? I have an identical problem in my script, and I haven’t thought about ways to solve it yet.

awake could be a good example.
Each step value is represented as a param. They are split into 2 groups, one for each pattern.

I guess in euclidigons’ use case, each shape should be a group, with a sub-param for each of its property (speed, note, shape, position…).
This is closer to how timber/player handles params for each sample.

2 Likes