#22

set_action will assign a new callback for parameter changes replacing the original callback that talks to the engine, there’s no need to do that. the parameters screen is redrawn periodically, so i assume that your code doesn’t actually set the parameter values. i think you can add some debug print statements in your code to see if you’re setting the right params.

#23

How hard would it be to implement live buffers into Glut? I’m thinking no quantization, just a simple asynchronous (granular) looper.

4 Likes
#24

I wonder if there is a way to have glut read from a softcut buffer?

4 Likes
#25

From my understanding of the Glut engine it can only read from a file, but maybe one can implement a softcut buffer(or maybe there is a simpler way with supercollider, since one only need a simple recorder) with an automatic filesave that glut can load automatically as soon as its saved. Would need to implement some automatic cleanup of files on shutdown or startup.

#26

in other news, I have a 64 version of Glut close to 100% complete. Would you mind expanding slightly on how the pattern recorders work @artfwo ? I think there might be something buggy about how I’ve implemented them in my script.

2 Likes
#27

Thank you! This is very helpful.

#28

i have been jamming some noiz on this script for a while now…really FRACKEN amazing!

would it be possible to add some arc support to it?
maybe just the four most useful noiz controls for each track?
(i guess there would need to be some sort of track focus for that)

anyhow…really cool interface!

1 Like
#29

that’s right, sending softcut buffers to supercollider is not currently possible and not neccessary for glut actually, as supercollider can record audio.

the tricky part is to design the recording workflow and UI in a usable way. with supercollider you can only record to pre-allocated buffers, so the length has to be pre-set, which requires some kind of UI and logic to do that.

sure, what kind of problem are you having?

yes, it again requires some UI design to go through the channels. I suggest you also check out Mangl by @Justmat, which is basically glut controlled via arc, maybe you’ll find it useful too.

2 Likes
#30

yes, it again requires some UI design to go through the channels. I suggest you also check out Mangl by @Justmat, which is basically glut controlled via arc, maybe you’ll find it useful too.
[/quote]

heh!
Mangl is what inspired me to ask if Glut can do that.
:stuck_out_tongue:

#31

thanks for the answers!

for one, the buffer issue: Could one to a bpm/bars interface to set the length of the buffer? not sure how to implement this, but it’s my “best” idea so far(this would in theory make it possible to sync with other equipment as well)

So my understanding of the pattern recorders is this:

Blink - armed, ready to record - press again for recording - and again to stop(?)
Then after that it gets a bit fuzzy for me(most likely do to a bug in my modified 64 script).
Is it press the pattern recorder again to play pattern? and then press again to stop?

#32

no, it’s more like:

  • press an empty pattern button to arm
  • press any other button to begin recording
  • press pattern button again to stop AND being playing
  • press again to stop
  • press again to play
  • press ALT+pattern to stop/clear the pattern

where ALT is the rightmost button in the top row

1 Like
#33

Makes alot more sense. Will do some testing tomorrow night to see if the 64-mod matches this behavior.

#34

I would very much like to add realtime input to the Glut engine. It seems that it’s a matter of adding a new function similar to readBuf replacing the call to File.exists with a call to In.ar. Then expose a parameter to write to the buffer with this function. I’m simplifying but this seems like the pattern.

The problem is everyone is using softcut 2.0 for “input stuff”. The JACK graph in Norns 2.0 does not connect the output of softcut to the input of supercollider.

@artfwo does this seem like a reasonable direction to add realtime input to fill buffers?

5 Likes
#35

i don’t understand the problem. supercollider still gets ADC input. you can use RecordBuf or WriteBuf with In.ar(context.in_b) or whatever, to capture to the Glut buffer.

if you actually want to feed back softcut output to supercollider, it seems better to add a second pair of input ports to scsynth. remember that scsynth can currently feed softcut input. it would break stuff (e.g. my performances) to make a constant loopback in the other direction.

hope that makes sense

1 Like
#36

Thanks for the confirmation. I graphed that out by looking at the jack connections. I didn’t know if this would be the best way forward. I also used mlr as an example for “doing sample stuff” which doesn’t have any engine loaded.

I’ll just use the inputs exposed to supercollider.

5 Likes
#37

woof sorry i was rude, v tired last night i guess

#38

Psyched about this! Was hoping to do something similair myself.

#39

supercollider can granulate realtime input, if that’s what you want, see GrainIn documentation. recording buffers for granulating them later, on other hand, is a nice thing to have, but don’t yet have a clear idea of a (reusable) interface for it in both the engine and the script, i.e. saving buffers to disk, etc. do you have any suggestions about that?

#40

it’s okay, I speak hacker.

#41

That’s partly what led me to the idea to tap softcut. @its_your_bedtime made reels a library so all UI stuff for filling buffers and writing to disk would “just work”.

1 Like