Great ! Thanks for your reply and for all you do for this awesome module of course
About faders, i have been playing a bit with them recently, and i am wondering if a type of fader where the “decrease step” and “increase step” buttons are right next to each other (following the direction of the fader of course) would be helpful to allow more simultaneous fader adjustments ?
Ie, in the simple case of a row of faders, a single finger could be assigned to each fader.
I am not sure if the ergonomics of that would be closer to a physical fader than the existing implementations. And then arises the problem of visually delimitating the upper end of the fader.
Maybe i am just a bit impatient waiting for the faderbank sources to see the light of the day. ^^
that’s a cool idea! not sure if it warrants adding a new fader type though…
Hi all, wanted to write here in case some might be wondering and powering the Grid directly with new TT.
I have the latest revision of TT, and I have been running the Grid directly into TT without external power, running Grid Ops, and have not encountered noise issues. I’m using an Intellijel tps 30 with the meanwell gsM60A15, and I think I’m almost maxed out on the power on my +12.
So good news?
Ok Maybe I spoke too soon. Left everything on for a bit and when I came back, screen on TT was off completely but the patch kept playing. Don’t know what happened, but after power cycle, it works again.
There’s a screensaver on the TT, if you left it for more than 90 minutes, that’s probably the reason
"Screen saver engages after 90 minutes of inactivity"
Yes! Saw that soon after I posted that last message lol good to know, so all is good with direct Grid powering with TT
if the screen goes to sleep while grid is connected you can just press anywhere on the grid to wake it up.
It didn’t wake from Grid press actually. I power cycled cos I thought something went wrong. Immediately after that, the keyboard also wasn’t working properly, and I had to connect keyboard to my computer, reconnect to TT before it worked again. I was using Fugetta for jf patch when this happened.
double checked the code and should clarify: pressing on grid will only wake it up if you’re in grid control mode (since using it implies you want to see the screen). otherwise it won’t, the reason being - if you are using a grid scene you might not want the screen to be kept “awake” whenever you press a grid button. if you do want to exit the screen saver in such scenario just press the front panel button.
re: keyboard - yeah sometimes it fails to do the handshake, just disconnect and reconnect and it should take care of it.
Thanks for this info and for checking!
Hey, maybe the wrong spot to ask but I think I saw a post saying that it IS ok to power the grid via teletype. I don’t have the new one but I’m wondering if this is true? I believe the post I saw said that whatever was considered to be the problem between the two was incorrect. Thank you
yes, you can connect grid directly to teletype. the earlier reported issue after investigation turned out to be unrelated.
it is possible however that with too many LEDs lit teletype will not be able to handle the load in which case it will shut down and require a power cycle, but it won’t get damaged.
Awesome! Thanks very much
Does the MLR script need to be edited by the user in any way to make it work how it does in your IG video?
I’m only able to have it advance and send a trigger out from the internal clock of teletype. When I load it up it’s sending triggers out on 1-4 on every clock pulse.
I’ve gotten as far as setting up a chopped sample in the ER-301 and having it play all the slices but only when teletype has M.ACT set to 1. When I turn it off and have a clock running into input 1 it advances the step on the grid but isn’t sending a trig out of 1. I also noticed that when you paused the track on the grid it sent a trig out whenever you picked a slice to play. When I stop a track from playing I am unable to move around the slices on the grid manually. I’m sorry if this is a waste of time I’m new to teletype and have spent a few hours trying to figure this out before asking. I pulled the mlr2.txt script from a post on this thread
yeah it’s possible the script doesn’t work anymore. i’m planning to work on grid studies soon and will revisit the mlr script as well, long overdue!
Ahh ok I feel a little better now knowing I didn’t completely miss something here. Thanks for the heads up. Time to get going on the basics so I can get up to speed and hopefully contribute here one day.
I am having a lot of fun with grid ops: it is changing how I make music. I am starting to run into very hard limits due to lack of script space, however.
One thing that would help is if grid setup could be done in one scene and preserved when the scene that runs/processes the grid is loaded. Right now loading a scene wipes out everything–which prevents setting up the grid in the first scene. I saw a discussion somewhere on lines about some variations on the SCENE op that preserved certain data and/or executed the target scene’s init script–this would be wonderful! I think we’d need variations to cover (non-)preservation of button state and control elements.
What would help right now is being able to preserve control element definitions from the first scene while loading button/fader state from the second scene. This would save me at least 3 full scripts over what I’m doing now, which is the equivalent of 50% more script space!
Ah but loading a scene using the
SCENE OP doesn’t wipe anything have fun!
Ah I misunderstood, and yes I echo your desire for more variations on that OP!
yeah it’ll have to be a new op, since changing
SCENE to not reinitialize grid controls would mean all the existing scenes would need to be modified to add
so maybe something like
SCENE.G scene which would load the specified scene without resetting grid controls? i believe control states do get loaded when using