#21

Thanks for this great script. I had a lot of fun with my OP-Z and Gridstep via MIDI.

(Little thing that I noticed. When changing the pattern it says „Patern A“ instead of „Pattern A“)

1 Like
#22

@klingklangmatze very happy to hear you’re having fun with it and are using midi out. Thanks for pointing out the spelling error, just pushed a fix.

#23

@Hlp I’ve changed the engine to Timber. 16 sounds are available, the track’s midi channel is used to determine which sound to play currently. No UI yet, but all the sound parameters are accessible in the Param’s menu. Looking into making the 1st sound a Timber player.

Molly The Polly can be used by editing the top of gridstep.lua and changing _MOLLY_ENGINE to true and _TIMBER_ENGINE to false

3 Likes
#24

Wow you are on fire!:slight_smile:

I wish i could test asap but i will find a way to acsess a pc somehow to dl it.
If i get it right you are still shaping it for a final release.
From your description i am not sure if you allready have a -free note grid playing - looped as pattern recording - with midi and timber player as sound source. But looks like thats about right.

#25

@Hlp might be a while til I have the “final release”. More like an ever-evolving piece of software that I’m working on to be my main midi-sequencer. All the features listed are fully functioning. You use shift(x2, y8) and play(x1,y8) to enable recording. Then press play and any keys you press will be input to the current pattern. If a step has no notes, then the steps note length and time offset will be determined by when you pressed the key and how long you held them. If the pattern loops and the step already has notes, the keys are added to the each step.

I’d like to add other recording modes though, such as a step mode that will auto advance when pressing grid keys. And also a freeform mode that will start recording on the first key press, and then determine the tempo and place the steps after you finish playing(which would be more similar to earthsea).

1 Like
#26

@Quixotic7 any chance this will wind up in maiden soon? I cannot for the life of me get this installed through dust :grimacing:

I shouldn’t be installing the lua files in the lib folder somewhere else, correct? I am dropping the entire gridstep-master folder into /dust/code and can’t get beyond the load fail error. This is the first time I’ve encountered such an error when installing this way.

I recognize this must be something with my norns since others have successfully installed!

1 Like
#27

try removing -master, so the folder is named gridstep. the script is looking for libraries inside gridstep/lib, so if the folder is named gridstep-master/lib, it won’t find them :slight_smile:

1 Like
#28

Thanks, @dan_derks, that did it! I typically leave the “-master” so that I remember to remove that version once something makes it to maiden, but I suppose I hadn’t previously installed something with libraries :slight_smile:

#29

@Gexex Yay! Glad you got it working.

@dan_derks thanks for helping @Gexex

I’ll update the documentation to specify it should be in the gridstep folder.

3 Likes
#30

+1 to this. as long as timber is installed doing this makes it easy peasy!

1 Like
#31

This is brilliant, thanks for sharing it.
I have just started with it but I’m enjoying it a lot.
Special thanks for:

  • start/stop option. This is something scripts often don’t have but I value it greatly.
  • visual feedback for the function of the grid toolbar keys. This should be widely copied!
  • really good paging implentation
  • and most importantly, fun and inspiring to make music with
3 Likes
#32

This is great! I’m happy to have timber linked to grid keys with scale mappings, and there is a sequencer on top of that!?! Amazing!

One strange thing I’m noticing, in the params settings I’m trying to change sample start and end points but the scale seems totally off, the very smallest steps I can make while holding k3 are 22.7 seconds (usually something like 0.1sec or 0.05sec) and the default end is 12.6 hours!

I have some piano samples that I’m trying to use that are 15 sec long but the actual hammer strike is about .5 sec into the sample, I’d like to be able to trim the silence off (without moving these samples over to my computer and trimming) but the params menu time scale issue isn’t allowing that.

EDIT: reloaded the script and now its fixed

1 Like
#33

Thanks for checking it out @coreyr ! I agree adjusting the sample params via the param menu is less than ideal and does some weird things. Planning to add UI elements for this. Like changing the loop points doesn’t seem to work after loading a new sample.

Please let me know if you find any other bugs or strange happenings.

I was out of town for Thanksgiving so couldn’t do much development, but I did jam with gridstep quite a bit and finding all the things that frustrate me, so hopefully by next week I should have a nice update!

1 Like
#34

@coreyr - I’ve added UI pages for Timber. No more need to adjust from the params menu.

4 Likes
#35

New update adds feature to send program change or midi note events when changing patterns! https://www.youtube.com/watch?v=DlUwQmZqUnM

1 Like
#36

getting this error when trying to scroll to the delay page after this mornings update:-

lua: /home/we/norns/lua/core/clock.lua:82: /home/we/dust/code/gridstep/gridstep.lua:3979: attempt to index a nil value (field ‘?’)
stack traceback:
[C]: in function ‘error’
/home/we/norns/lua/core/clock.lua:82: in function 'core/clock.resume
:wink:

1 Like
#37

A couple of issues I’ve noticed:

  • when syncing to external midi clock, start and stop work, but the sequence gradually gets out of sync with the midi clock. I don’t know if this is a GridStep thing or a Norns thing? Does the script ‘listen’ for incoming clock or just to start/stop messages?
  • the Norns UI and inputs become unresponsive when performing some actions. This is fixed by pressing key 1 twice, which often results in a black screen, but then turning e.g. E2 prompts a screen redraw and input works again. This always happens for me when choosing to load a saved instance for example. I don’t think I’ve noticed this as being an issue with other scripts but I should do more tests to be sure this isn’t just a general thing related to my setup here.

EDIT: to be clear this is not related to the latest release, which I haven’t installed yet. I’ve had it for the last few versions I’ve installed.

1 Like
#38

Thanks for pointing this out @martindunne . I’ve pushed an update that fixes the crash.

@Lemmy thanks for pointing out these issues! Can you let me know what version you’re running, should near the top of gridstep.lua local version_number =
The norns UI is probably becoming unresponsive due to the Timber waveform loading when switching tracks/samples. I’ve fixed this in the latest release.

How do you have your clock sync setup? Is norns clock set to internal, midi, link, crow? The script listens for start/stop messages and is syncing with the built-in clock class. I’ll have to do some experimentation and determine if I also need to adjust using incoming clock messages.

1 Like
#39

Been doing some testing with midi sync.

If I sync to an external midi source, it can become slightly out of sync if I do a CPU intensive action like loading a Timber Waveform, changing a sample, or loading a new song.

I’m not sure what the best way to fix this is. Would love any suggestions?

When using the internal clock to sync, everything stays in sync even if loading waveforms, changing songs, etc. Except if changing the tempo really low then high. So I’d recommend making the norns the master clock for now.

#40

literally just tackled this issue, really glad to have confirmation that i’m not out of my mind :slight_smile:

you’re running at 48 PPQN, right? and you’re tracking these pulses for the microtiming?

basically, what i’ve found is that these external clocking hiccups manifest as either double-pulses in the space a single pulse or dropping a pulse entirely. that slides everything either 1/48th beat ahead or 1/48th beat behind, which compounds as the script continues.

i managed to compensate for this by checking in on the beat count at every reset (eg. where my micro-step counter is equal to 1) and making sure that i’m on on a whole beat rather than a whole beat +/- 1/48th. if i’m not, then it compensates by 1/48th each reset until i’m on.

big glitches might take a few rounds to compensate, but it definitely will get back on track – it might also be easy to account for these cases with some simple maths (eg. if the distance is greater than +/- 1/48th, then compensate by however many 1/48ths will help get back to the beat).

some version of this in your script should help gently course-correct in all cases (external derivation or CPU overloading): synced-test-better.lua (1.9 KB) (this is best version, as of 3:52p CST).

might need to adjust the remember forgiveness, if it gets too aggressive :muscle:

1 Like