#44

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
#45

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
#46

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
#47

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
#48

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
#49

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

2 Likes
#50

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
#51

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
#53

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
#54

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
#55

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
#56

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.

#57

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
#58

sure! Dogme 95-style video below (turning on the flashlight helps my phone read Norns’ screen better) –

Technically speaking:

  • Blur kicks in as a shape starts to rotate close to +/- pi / (number of polygon sides * 2) radians per frame, which I’m thinking of as a visual Nyquist frequency. At “Nyquist,” blur is 1.0, and as blur approaches 1.0:
  • The filled circles that are normally drawn for individual vertices are replaced by a single stroked circle. whose radius is the distance between a vertex and the center of the shape.
  • Lines normally drawn for sides are replaced with another stroked circle, inside the circle formed by the vertices. Stroke width is dependent on the number of sides: it’s the difference between the radius of the shape and its apothem (the distance from the center of the polygon to the center a side; just learned this word a few minutes ago, time to go rename some variables).

I’ve got a little ways to go before I feel good merging this in – there are a couple audio glitches in the video, probably caused by too many engine.*() calls in quick succession, and there’s a limitation in the way I’m currently doing collision detection that starts to reveal itself when you get a shape spinning extra, extra fast (like 2pi radians per frame) – hoping I can resolve that in a way that won’t offend Norns’ CPU too much, though there should probably also be some upper limit to how fast these things can spin.

thanks, @eigen – that approach makes sense, I should probably get over the resistance I’ve felt toward numbering the shapes, at least for this purpose.

8 Likes
#59

An intrasite link to a couple of videos recorded live using Euclidigons and a smidge of MS-70CDR FX.

1 Like
#60

Thank you for sharing these!

Euclidigons is the first time that software that I’ve had a part in creating is being used for something other than commercial gain (FileMaker consulting is my day job). This is far more rewarding than that so again, thank you! :pray:t2:

2 Likes
#61

Well done - it’s a very rewarding script to use, and one which draws me even more to Norns each time I use it.

3 Likes
#62

Made it! Catching up with these scripts and threads takes a whole evening but this is such an awesome piece of work! Ever considered arc implementation? Or would that be silly?

3 Likes
#63

Definitely not silly – I’ve considered it but, so far, not much more than that, even though any spinning object-based script deserves Arc support.

Do you have specific things you’d like to be able to control via Arc? The most obvious choice would be to control one parameter (rotation rate, position, size) of four shapes simultaneously, but I’m curious if you have other ideas.

BTW, I’m finally moving on the params / MIDI mapping idea. Expect everything to be MIDI-mappable soon.

2 Likes
#64

Cool - I’m just getting my head into it - multiple shapes was a game changer. In terms of arc, well…

What I like is to use the script like an instrument, where I manually collide the shapes and then out again. You can make wonderful structures and musical movements doing this but it involves switching to the shape via ENC 1, and combinations of ENC and K’s. I worry about those little knobs on the norns. With an arc you can become more gestural.

On an arc I’m guessing you could free up this kind of interaction and assign each dial to a shape and therefore extend this principle so it becomes much more performance based. I’m pretty sure that you could utilise the arc to control sides and speed. With four dials you can have four shapes. I can see it becoming a wonderful performance tool. If you could switch notes seamlessly that would be ace swell.

something akin to Strettas rhythm machine https://www.youtube.com/watch?v=HM0EBvJe1s0&t=194s

I have no idea how to code this in Lua, but it would certainly extend this already awesome script!

4 Likes