#159

study 3 introduces metros and spends a substantial section explaining them. can you clarify further?

#160

I think the addition of the online link would be helpful to some.

In study 3 the first mention of metro is under the ‘time again’ heading and it seems pretty clear that metro is a metronome. I can possibly see where study 2 could be improved since it mentions metro in isolation.

1 Like
#161

OK, so I hadn’t spotted the reference in study2. In study 3, while it’s reasonably clear that we’re talking about a metronome, if we think about users learning Lua while also learning Norns, then we’ve just introduced a thing (an instance of a class I’m assuming) without mention of what it is that we’ve added.

The text says " this init function creates a metro called counter", and then dives into it’s members and methods (sorry, I’m learning Lua too, so apols if this isn’t the right terminology) without saying what this metro thing is.

For me, it jars, maybe for others less so??

#162

I think I see what you mean. If you come to the studies from a computer science background, you may want to see the API right away. It can be a little frustrating at first to just ‘go with it’, but I think once you do them and start creating, that goes away. It’s a different experience reading through the studies versus interacting with them and Norns.

1 Like
#163

That’s a fair comment.

#164

preceding the code block and init explanation:

in addition to using keys and encoders to trigger functions, we can also make time-based metronomes which trigger functions.

open to suggestions (and PRs) for specific elaboration

in addition to the API we’re working on a “programming reference” which will distill all of the concepts introduced in the studies

5 Likes
#165

I missed that. Sorry for the noise. A programming reference sounds like a good addition.

#166

Any plans for an Arc study in the future? I’ve been reading the API reference, but would benefit from some simple examples/tutorials to start from…

5 Likes
#167

In we/study/study2.lua why is it that when i swap circles in for rectangles; I get this extra drawn line?

screen.circle((0.5+m*9)+3, (0.5+n*9)+3, 3) 
--screen.rect(0.5+m*9, 0.5+n*9, 6, 6)

Is this a bug in the screen drawing api or am i doing something silly?

nornsCircles
nornsCircles.jpg3024×4032 2.99 MB
nornsSquares
nornsSquares.jpg3024×4032 3.08 MB

update: i tried a setting the level to zero just about everywhere before the first circle is drawn. Didn’t help. so i added this move right before the circle draw command. Looks to me like the circle command needs to track before it draws.

screen.move((0.5+m*9)+6, (0.5+n*9)+3)
screen.circle((0.5+m*9)+3, (0.5+n*9)+3, 3)

update 2: Adding a stroke to the beginning of redraw fixes the issue, but thats obviously not right:
function redraw()
screen.stroke()
screen.clear()

#169

Hello. My first post here, so apologies if I put it in the wrong place…

I want to take a crack at getting an ipad to mimic a grid. This topic comes up periodically, but I didn’t find that anybody succeeded. The tutorials file osc.lua got me halfway there! It connects with touchosc, and I parsed the string from a multitouch grid into grid coordinates. Now for the slightly harder part - I need to be able to send strings to the ipad. In puredata you just connect to a port and use netsend and netreceive. I have found lua examples that look promising, but they give errors - I don’t think these packages are pre-installed?

string ="/led11/1"
cl=net.createConnection(net.TCP, 0)
cl:connect(10111,“192.168.1.115”)
cl:send(string)

I think that simply connecting to a port and sending/receiving OSC messages should be possible - I can’t find out how this is done with the norns commands

function connect()
osc.event = on_osc_event
end
function on_osc_event(path, args, from)

Anyway - I don’t speak lua and am a physicist, not a coder, so this should come across as uninformed/novice. But any help would be much appreciated!

-Gerald

#170

Hi Gerald (welcome!)

Not sure if you’d already worked through the studies or not - Study 5 hits on some basics of using OSC from Max (should be similar from pd).

Here’s a copy of Study 5 if you want to grab it and drop it onto your device (at ~/dust/code/we/study/) study5.lua (3.4 KB)

for your situation (mimic a grid) I think what’s needed is a little OSC-to-grid library… so that maybe you could drop this in, change a line or two of code and get the touchosc grid working with other scripts.

I’m gonna try a few things and report back.

#171

hi gerald curious if you’ve made any progress on this?

#172

It mostly works. Needs a bit of help. Thread here:

#173

On study 4, with my GS64 I’m not able to get the sequencer running.
It’s surely related to the non varibright quality of my grid but is there a workaround?

#174

are you able to get any lights to turn on? do you get key feedback? do you have the grid selected in the SYSTEM > DEVICE menu?

#175

Yes, my GS64 is working. I can use it with apps like Awake.
I’m reading the studies. In the Physical part, I cannot get the sequencer running. Since my grid is a non varybright one, this could be a syntax thing.

#176

I also have a GS64, and I can’t get the sequencer to run, either. After copying and pasting the code from the lesson (which comes after “let’s take this decoupling a step further”), I have the following error:

# script init
metro_stop(): pthread_cancel() failed; error: specified thread does not exist
metro_stop(): pthread_cancel() failed; error: specified thread does not exist
>> reading PMAP /home/we/dust/data/sketches/grid_test/grid_test.pmap

I tried changing the sequence length and modulo to 8, but to no avail. I also saved the script and restarted in case it was an engine thing, but from the command line I can make it make notes. I can also ask it what position it’s in, and it remains in the init position. It’s also worth noting that the grid redraws – I can choose values and they are stored in the appropriate tables.
I change g:led(i,steps[i],i==position and 15 or 4) to
g:led(i,steps[i],i==15)
so I can see all the steps, but the metro doesn’t run. I can get the other metro scripts to run without using the grid. And the grid works with Earthsea.
Thoughts, anyone?
– note, running GS64 on DIY Norns/3B+ with no USB hub, plugged in with sufficient power supply

#177

sorry i don’t have any particular insight on the actual problem (will look if i get a minute), but fwiw:

those pthread_cancel errors happen a lot, somewhere metros are sometimes being “double stopped”, i haven’t been able to track it down but have also not observed any resulting problems.

#178

Yeah, I’ve now re-run the script and am not getting those errors any more… (sequencer still isn’t running tho).

#179

a quick visual inspection suggests that study 4 is using old and wrong syntax for specifying metro callback and thus it is not working. try changing callback to event. (i also think it’s gratuitously confusing to name the callback function count when the metro count field is also named that.)

@tehn or whoever, looks like study 3 has been updated but study 4 needs a look

2 Likes