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

Yeah, I’m running at 48 PPQN. Thanks so much for the script example! I’ll try implementing this logic tonight and see what happens.

2 Likes
#42

for sure! ymmv, you might need to add some additional logic to reign things in (i’m actually finding better results with 1.5/t.resolution, otherwise it gets caught in a lil loop and ends up pulling off a full beat – i updated the file above), but it’s a start – running 480bpm on link over public wifi and we’re in sync for 1400 bars and counting! :slight_smile:

edit: here’s maybe an even more adaptable version synced-test-maybe-best-who-knows.lua (2.4 KB)

3 Likes
#43

Hi,

The version is 1.3.1
I’ll try the latest update and report back. Norns clock was set to midi. Looking at your subsequent posts I think the sync problems were worse with my set up. I was sending midi clock from Bitwig and the sync would go noticeably out over say 16 bars. Of course I can use Norns as clock source so it’s not such a big deal.

Thanks for looking into this!

#44

I just updated to 1.3.5 and I’m still seeing the unresponsive behaviour when loading saved instances. If noone else is reporting this I guess it may be a quirk of my setup.

To reproduce - presuming you have saved a performance in GridStep:

  1. In GridStep screen 1 select Load
  2. UI displays list of saved files but no longer responds to input from buttons or encoders

To workaround:

Press K1 twice. Screen is now black, but turning E2 prompts redraw of list of saved files and selection is now possible.

For context, I’m using Norns Shield and Neotrellis Grid, so full DIY. Norns version appears to be 201029. Perhaps I should try updating that.

1 Like