#317

exacty, my intent in this case was for G.BTN.PR .
I’m trying to create a scene where samples are triggered mlr style with button presses and quantized to clock on the ER-301, and looped using the new pedal looper unit - looper controls assigned to buttons on the grid.
emulated presses are for the random triggering option, where I would like to have another page to assign probabilities for each step, and that’s where I had this problem with disabled groups. It would be of course possible to write this another way without using G.BTN.PR but its just much more convenient and it saves a few lines , I think.
hope that makes sense.

2 Likes
#318

i’m still not entirely clear on your use case but i think the change does make sense (i thought the workaround could be simply calling the script assigned to the button you “press” but then you lose the ability to use G.BTNV \ G.BTNI etc shortcuts, and there are some other subtle differences between emulating a button press and calling a script directly). i’ll make the change in the next version.

this also made me consider what would happen in this scenario:

  • create a button and assign script 1 to it
  • in script 1 call script 2
  • in script 2 emulate pressing the button

my concern was it would cause it to freeze as it would enter an endless loop, but the recursion detection works properly in this case as well and stops it after 4 iterations.

3 Likes
#319

thanks! those shortcuts were the reason why I used emulated button presses, plus I like to have visual feedback on the grid.
sorry I wasnt very clear about the use case; I’m still trying to find out how to write what I’m trying to do.
the short version is, the script is emulating random button presses when its triggered. I want to go to another page on the grid and change some faders while its still running.

1 Like
#320

@scanner_darkly really enjoying my time w/ the grid ops!

An issue I’ve become curious with, is that my faders seem to switch intermittently between moving instantly to a new value upon a press and moving to the new value with what feels like a slew. Had this problem briefly while making the fader group in the simple seq patch and have stumbled upon it again with a single fader in my own patch. In my patch I had this problem for a few minutes, then w/o a reason I could recognize the fader began working normally a few minutes later it returned to the slow movement between presses.

I’m getting this behavior in both the visualizer and the grid itself. Going back to the simple sequencer, I’m noticing that I curiously only have this issue on faders 2,5,7,9,10,12,13,14. As a shot in the dark, I tried G.RST and reinitializing the patch, and now the sluggish faders are 3,5,6,9,10 (where the other faders jump quickly to the new value).

While I’ve had this issue days apart, I also tried a reboot and now the sticky faders in the simple sequencer are faders 13,14 with the rest working as expected.

I did a quick refresher through this thread and a few searches I thought might bring me to this being previously discussed, so apologies if I missed a glaringly similar query above, but I’m curious if there is something I’m missing here?

I’m on the 2.3 beta 1

thanks!

1 Like
#321

what you’re seeing is fader slides getting triggered due to “stuck” grid buttons. fader slides are triggered by 2 keys pressed simultaneously. for some reason sometimes it doesn’t get a release from the previous key, so to firmware it looks like 2 keys are pressed at the same time.

it’s actually easily reproducible in grid visualizer, if you press alt-space then while holding it press an arrow it’ll interpret it as the first button still being pressed (i used it to emulate press+hold this way before, but now it’s not needed as you can do the same thing by expanding selected area and then doing a press). i also noticed it happen sometimes when switching from keyboard to grid.

i just finished making a couple of changes, basically, disabling the behaviour described above (now if you move away from a pressed button it will automatically release it), as well as resetting any held keys when you plug the grid. i’m hoping these changes should address most scenarios. i should have a new beta likely tomorrow, for now the fix is basically pressing every button in a fader until you hit the one it thinks is held, after that it’ll return to normal operation.

4 Likes
#322

new beta posted here: Teletype 3.0

what’s new for grid integration specifically?

  • “sticky” grid faders hopefully fixed, basically i did what i described above (cc @tambouri)
  • G.BTN.PR and G.FDR.PR will now work on disabled controls (cc @derz)
  • fine faders not working properly with levels higher 127 fixed (cc @dan_derks)

next beta will include some cool new grid ops!

6 Likes
#323

After a night’s TT workout, I have not had any more issues w/ sticky faders. And P.HERE is working as expected while monitoring the pattern page

Also played w/ using L 0 15: $ 2 and calling I in the script 2. While I haven’t tried the fringe cases mentioned in the beta thread, it appeared to be working exactly as expected.

I think I lucked out w/ my issues being so close to a beta release, but that was an impressive turn around.
thank you

4 Likes
#324

it was great timing, i literally just finished working on sticky faders when you posted :slight_smile:

thanks for testing, great to hear it’s working now! and thanks for reporting the PN.HERE bug, those are the kind of bugs that are difficult to spot (i checked other pattern ops and this was the only one that had the issue) but can really break the workflow when you’re in a middle of a scene and trying to figure out why it’s not working.

2 Likes
#325

Mr. @scanner_darkly could you elaborate on the ‘horizontal’ and ‘vertical’ options for faders? I’m not quite grasping those settings in relation to the width and height settings. Seems like one has to manually set both the width and height to reflect which way you want the fade to go AND the fader options to the same setting, if that mkakes sense.

#326

for faders direction is determined by the specified fader type. direction affects its operation, whether you change the value horizontally or vertically. it’s not related to width and height at all, so you are free to make, say a 5x5 fader which can be either horizontal or vertical.

in most cases you’ll probably use the width of 1 for vertical faders and the height of 1 for horizontal faders, but in some cases “thicker” faders make sense, so the ops give you the flexibility to do whatever works best for your scene.

2 Likes
#327

thanks, Monsier Darkly, that helps!

1 Like
#328

I keep thinking about the possibility of a keyboard emulator mode using the Grid to type… or I guess I could roll an external switch which routes the Grid into a RasPi, turning serialosc input into HID output. Regardless, typing on a featureless orthogonal keyboard might be tricky. :rofl:

3 Likes
#329

That’s interesting! I have a vague memory of a specialist input controller in the 80s which had just 6 (or was it 8) buttons. The user would ‘draw’ a shape representing the letter they wanted to enter.

Another possibility could be a system similar to old mobile phone keypads, where the top-left pad would be used for “A, B, C” depending on whether you tapped it 1,2,3 times.

Not very practical for entering scripts but interesting to think about the possibilities (to me, anyway!)

1 Like
#330

that’s crazy, i love the idea! but probably not very practical, it would still be easier to just plug a keyboard…

could just use braille, you would only need a 2x3 button block. this does make me wonder if there is some possible practical application for it as it would be easy to implement.

on a related note, the next feature i’ll be working on is using grid to load/save scenes, trigger and mute scripts and do a few other things.

4 Likes
#331

Man… Grid is sold out right now…

#332

not a proper replacement, of course, but you can try grid integration even without a grid - the grid visualizer can be surprisingly effective for some scenes.

2 Likes
#333

The converse idea occurs to me: using a HID keyboard as a grid. (No lights of course)

1 Like
#334

did consider that but i think the lack of visual feedback would make it not super usable…

2 Likes
#335

having recently spent a few days working on my first grid+tt+er-301 scene, i found the grid emulator (the first one accessible with Alt+G from the prompt screen) very useful and barely needed to switch between keyboard and grid.

One thing about the keyboard shortcuts, though, was that i wish this grid emulator (the small one, not the fullscreen one) were accessible with the ~ key, in the same rotation between empty prompt and variable display. I can live with Alt+G but i feel that ~ would make overall navigation a tiny bit leaner.

1 Like
#336

it would be definitely more usable, however grid integration must be done in a way that doesn’t interfere with the workflow of folks who don’t use it. therefore a separate shortcut seemed more appropriate. we could revisit this in the future once 2.3 is officially released and more ppl had a chance to try it.

1 Like