#921

Although I completely agree that it is too brave to update before performance I also think this is a good idea. I am often away from a laptop and don’t want to take my phone and 99% of the time I am just updating all scripts without reading release notes anyway so this will be much easier to just do it from norns.

#922

I’m not saying to update it right before the performance, but while rehearsing. Sometimes bugfix update can fix some annoyances that you have been struggling with whlist trying out some new functions.

1 Like
#923

understood! i can throw together a proof-of-concept

3 Likes
#924

you could just run maiden from your phone?

1 Like
#925

The infinitedigits solution is super tidy compared to mine but I thought I’d share this as I’ve found it really useful to allow me to have the polling set fast but not get loads of re-triggers. This one is using crow but you could just just pinch the re-trigger stuff or swap in the p_amp_in code wherever the crow stuff is. If you just need one then dump the socket stuff but you could also re-purpose that to be L/R inputs.

I’ve got this as a separate object that I can drop into the lib folder. Then you just add the include at the top of the client script, run the init at the bottom of your app’s init code, pass whatever method you want to call into the init and specify which port.
The threshold, hysteresis and hold time all come up in params so you can tweak while you tap.

I should warn you that the amplitude reading is probably not the peak. I guess it’s a trade off, if you want fast response then there’s alway the chance that you are triggering as the amplitude rises rather than at it’s peak.

Summary

– Crow Audio input driven event triggers
– Pass in callback function and it calls it with the amplitude, I think thresh->1, as the return argument
– Second init argument can be 1 or 2 or specify the input to listen to, defaults to 1.

local tr = {}
local function callback() end

local input_socket = 1

–audio input polling variables
local refresh_rate = 0.005
local amp_in = 0
local triggered = false

local hold_timer
local retrigger_hold = false

local function retriggerholdtimer()
clock.sleep(params:get(“retrigger_hold_time”)/100.0) – params map to 100ths of a second
retrigger_hold = false
end

local function triggerhold()
if retrigger_hold then – cancel the previous hold timer, edge case, prevent double offs.
clock.cancel(triggerholdtimer)
else
retrigger_hold = true
end
clock.run(retriggerholdtimer)
end

local function inputreading(amp)
amp_in = amp
–print(amp_in)
if triggered then --if we were already above theshold then see if we are now low enough to be ready for another transient
if amp_in < (params:get(“trigger_threshold”)/10) - (params:get(“trigger_hysteresis”)/10) then
triggered = false
end
elseif retrigger_hold then – if too close to a recent trigger

elseif not triggered and not retrigger_hold then – if not already above threshold or close to previous trigger
if amp_in > (params:get(“trigger_threshold”)/10) then
triggered = true
triggerhold()
print('trigger ’ … string.format("%.4f", amp_in) )
callback(amp_in)
end
end

end

function tr.init(cb, socket)
if socket == 1 then
input_socket = socket
elseif socket == 2 then
input_socket = socket
end

callback = cb
crow.input[input_socket].mode( ‘volume’, refresh_rate )
crow.input[input_socket].volume = inputreading

params:add_separator()
params:add{type = “number”, id = “trigger_threshold”, name = "trigger threshold "…input_socket, min = 10, max = 50, default = 30}
params:add{type = “number”, id = “trigger_hysteresis”, name = "trigger hysteresis "… input_socket, min = 1, max = 30, default = 10}
params:add{type = “number”, id = “retrigger_hold_time”, name = "retrigger hold time "… input_socket, min = 1, max = 30, default = 8}
end

return tr

#926

Idea: click track sync.

Some devices such as the Teenage Engineering Pocket Operators set tempo by syncing to a click track. This could be an interesting clock source for norns, to complement the internal, MIDI and crow clocks.

I have a horse in the race because I’ve dropped both my PO-16 and PO-28 smashing the screen. I have no idea what my PO tempo is, and lack basic DJ beat matching skills (I should learn it actually).

I am researching writing a little utility program for norns to sync the global clock to a click track from PO modes { SY_𝑚 | 0 < 𝑚 ≤ 5; 𝑚 % 2 = 1 } and for providing one to sync POs to { SY_𝑚 | 2 ≤ 𝑚 ≤ 5 }. I imagine using poll for this. This is definitely a weak solution as the chain wouldn’t stay in synch on tempo changes. But getting this into norns core as a global feature sure not seen like an entirely, utterly unsurmountable task looking at the C code which does clocks.

Anyone else using click tracks? :stopwatch:

3 Likes
#927

i do, and i also explored norns doing this at one point.

for norns sending click track - i opted not to do this because i want to keep as much stereo in my signal path as a i can :slight_smile: instead, i use another raspberry pi that sends out a click track with a utility program or a sequencer program. unfortunately those programs won’t run on the norns because the audio out is already taken by norns. a more norns-integrated way to do it though might be to make a supercollider engine that is activated at the script level.

for norns receiving click track - i tried this too, i liked the idea of having something start when the click is activated (like po’s do). i tried using poll and didn’t get far. i think i gave up though because i couldn’t figure out how to get high resolution timing without polling a thousand times a second…again a better solution is probably to utilize supercollider, as it has onset detection.

1 Like
#928

if your other program uses JACK, it can abslutely share the outputs with crone or be fed into the engine ports of crone. (i frequently use norns as a host for arbitrary audio processes sent through the crone mixer.) (if it doesn’t support JACK… it should :slight_smile: )

in fact, matron is entirely agnostic of what program is hosting engines. it only knows the OSC interface and the port number. (to more fully support alternative engine hosts, i suppose we should formally document the interface protocol and make the port number dynamically assignable.)

re: onsets, here is a gist
[ https://gist.github.com/catfact/2f591c7fa2d4e89a3358875bf8133896 ]
(this was a response to slightly different question [reporting pitch at time of onset for pitched percussion on norns.] but it demonstrates SendTrig which is a weird part)

further exercise: incorporate this into a norns engine and add a poll using periodic:false:
[ https://github.com/monome/norns/blob/main/sc/core/CroneEngine.sc#L35 ]

in engine class

Engine { 
var p ;
...
  alloc { 
      p = addPoll ("onsets", periodic: false ); // poll func is unused
    ...
  }

// ... in OSCdef action
   { 
      var x= msg[3]; // value from SendTrig, if any
      p.update( x );
   }
}

in lua, polls like this should be useable like any other, they just ignore requests to set the polling interval since they are driven by arbitrarily timed events on the engine side.

(i say “should” because i don’t think anyone has used this feature in earnest. i meant to make an onsets engine in response to your last q about this, but never got around to it. recently was considering that onsets would be useful enough to go in the system analysis stack alongside pitch and amp.)

3 Likes
#929

not sure if this has been discussed before, but it would be really cool to have more norns/crow/modular interaction with more gate outputs on the non-sequencer scripts. something like gates/triggers for each of the pads pressed in the 3 banks of cheat codes out of crow outs 1-3 - would have manual gates, euclidean/arp rhythmic patterns, random gates, etc. end of splice gates for each of the 3 tapes in reels, end of grain gates for 3-4 samples in mangl (maybe too fast but at slower speeds could clock sequencers, whatever with the rate of grains), etc, etc. have been reflecting on my norns/modular composition process lately and felt like this would open up a new world of interaction for me. i’m a supercollider novice, so i’m not sure if any of that’s possible, but maybe could lead to something useful.

#930

As mentioned in the Norns clock thread, multi device midi clock out would be very useful as an option in a proposed live setup I have. Either assigning midi clock to different midi ports (if this fits with midi standard) or assigning two outputs to the same midi port.

#931

@yoyosandshoes, logged this FR, thank you! https://github.com/monome/norns/issues/1275

@lilskullymane, these are great ideas which need to be realized by each script – you should definitely share these specific implementation ideas within each script’s threads, just in case the scripts’ authors and any willing community contributors aren’t seeing them here :slight_smile:

fwiw:

this is currently implemented in cheat codes – let me know if something’s not working as expected, tho! :sparkles:

2 Likes
#932

will do! and amazing, works right away exactly as i would have hoped! slipped past me in the timing section of the documentation, thanks :wink: can’t wait to mess around with this tonight.

1 Like
#933

Has anyone had a chance to explore this? I have recently been using Valhalla Super Massive a ton, it has become a huge part of my process. It’d be super awesome to be able to load it onto norns whenever live music is a thing again

#934

The VST plugin would have to be compiled for ARM, and I doubt any commercially available VST plugins are.

2 Likes
#935

I wonder if this will be a nice side effect of prep for m1 macs? see:

1 Like
#936

Ah I had missed that. Not entirely sure that would work on any ARM based system though.

#937

yeah…this is out of the realm of my understanding

#938

Would Linux VSTs compile to work via PD on Norns? I seem to recall running some via Reaper under Rasbian.

1 Like
#939

would it be possible to make an oscilloscope script for norns? i dont know if the waveform visualization for softcut would work for that, but i think it would be really nice, at least in my case where i have all audio running into my fates before it hits the octatrack, to have an oscilloscope open when im not using the norns for anything else

and if that oscilloscope script could also have some sort of midi thru routing in its map params or something as well, so i can send my nanokontrol which is always connected to the norns, through to my octatrack or A4, that would be perfect. i still haven’t figured out whether or not Passthrough is made for this/capable of this or how that works. just lik a “Utility” script sort of, for when you’re not running any specific script

3 Likes
#942

I know nothing about how fonts work on Norns but I feel like Mike Jittlov’s classic cornacopia of tiny pixels could be a good fit:

edit: more practical suggestion: I’d really find it useful to have version numbers / some indication of whether there’s a new version of installed scripts in Maiden installer

4 Likes