Super helpful thank you!


Hey @charlieroberts. I’m back with a few more questions, lol.
I’ve been exploring the integration with some Max patches and loving the results I’m getting with it.

My first question is about gaining control back via the Max gui objects after I’ve stopped the Gibberwocky control. I assumed that .clear() would work but it doesn’t seem to be. Am I using it wrong? I tried .stop() before the clear messages but that didn’t seem to make a difference. I also tried separating the commands with a carriage return in between.

l = line( 4, 2.9, 3.1 )
message( 'ratio' ).seq( l, 2  ).clear()
l.start.seq( [2.015,3.8,4], 2 ).clear()
l.period.seq( [1/2,1], 1 ).clear()
params[ 'Slew' ].seq( [20, 30, 80], 1.99 ).clear()

I’ve also noticed one persistent bug with the graph displays for visual feedback. It consistently removes the comma after the closed bracket here:

l.start.seq( [2.015,3.8,4], 2 ).clear()
and turns it into:
l.start.seq( [2.015,3.8,4] 2 ).clear()
I then get errors on upon that when I do the next evaluation.

As always, thank you!

EDIT: Sometimes the bug seems to remove the bracket FYI

Yeah, that graph display bug is really annoying. I’ll try to see if I can fix it this week.

In regards to stopping the sequences, there’s a bit towards the end of the “basic sequencing” tutorial that talks about how sequencers are assigned different ID numbers. Unfortunately, the tutorial doesn’t get into how you use these ID numbers, which is the info that you actually need.

In your case you’re only applying one sequence to each property, so all of them use the default ID of 0. This means you can target them as follows:

l.start[ 0 ].stop()
l.period[ 0 ].stop()
message( 'ratio' )[ 0 ].stop()
params[ 'Slew' ][ 0 ].stop()

If you create multiple sequencers targeting properties you then need to specify individual sequence IDs, as a third parameter to any call to .seq(), you can then use that ID to select that particular sequence for manipulation.

You can see a little bit more of this syntax for targeting sequences in the “patterns and pattern transformations” tutorial as well.

1 Like

Ah. Brilliant thank you!

EDIT: Sorry @charlieroberts , a follow up question.
That syntax doesn’t seem to be working with sequenced params. ie:

params[ 'Slew' ].seq( [820, 1030, 1400], 2, 0 )

params[ 'Slew' ][ 0 ].stop() 

I noticed in the documentation that params don’t have any methods mentioned. Does this explain why that doesn’t work but adding a .stop() does? ie:

params[ 'Slew' ].seq( [820, 1030, 1400], 2, 0 ).stop()

Thanks again!

Hmmmm… I can’t recreate this bug. Using the gibberwocky.maxhelp patch, I can run this line from the introductory tutorial:

params['White_Queen'].seq( [10,32,64,92,127], 1 )

and then stop it with:


… as well as restart it with a call to .start().

One other idea you could try… every call to .seq() returns the generated sequencer object. You could store that in a variable and then use that reference to stop/start. For example:

seq = params['White_Queen'].seq( [10,32,64,92,127], 1 )
// wait some amount of time and then...
1 Like

I’m curious on how to implement the accumulator if you get a sec.

I’d like the second value in both of the seq arrays to accumulate by an integer of 1 each time the seq loops. So the 1.75 and 4.8 values below:

message( 'ratio' ).seq( [1.5, 1.75], [8, 4.8] )

Should I store those values as variables and run accum on them?
I’m sure it’s not right as it doesn’t work, but something like this?

one = 1.75
one.accum(1, 1.75, 5.75)
two = 4.8
two.accum(1, 4.8, 10.8)
message( 'ratio' ).seq( [1.5, one], [2, two] )

Thank you for all your help.

Hmmm… so that’s getting outside of the built-in gibberwocky functions; we’ll need to write some (very short) custom JavaScript functions to make this happen. In our arrays, our second items will be functions that will return the value of variables. Then we’ll create a standalone sequencer that updates those values over time.

If you haven’t done much JS before ()=>{ //some code } is shorthand to create a function that executes a chunk of code, ()=>someValue is even shorter and creates a function that returns a value.

value1 = 1.75
value2 = 4.8
message( 'ratio' ).seq( [1.5, ()=>value1 ], [8, ()=>value2 ] )

Seq( ()=> { value1++; value2++ }, [ 8, ()=> value2 ] ).start()

Seq is creates a standalone sequencer object… these objects are created behind the scene whenever you sequence anything. In this case we explicitly create one and tell it to call a function that increments our values.

Please feel free to ask questions about this code chunk!

1 Like

Better way… we just define a function that increments its value and then returns it.

customaccum = (val, incr=1) => {
  return ()=> val += incr

message( 'ratio' ).seq( [1.5, customaccum(1.75) ], [8, customaccum(4.8)] )

In this example, the values increment by one by default, but you can also pass an optional second argument to customaccum to change the increment amount.

1 Like

Wow. This is really beautiful @charlieroberts.
Thank you so much!!!

1 Like

Back with two more:

  • I’m a bit confused on how to get fade to work. I tried this:
    params[ 'VelScaleALL' ]( fade( 3, 0.63, 0.8 ) )
    but I get a console message that says: socket live is not ready for messaging which makes me fear that it’s maybe a Live only command? I also tried .fade which is clearly incorrect as well. I’m guessing that I’m just implementing it wrong but is there something similar when using Max if so?

  • Is there a command to stop all of the sequencers globally?
    Like a way to script All sequencers stopped?

Thanks as ever!

1 Like

In regards to fade, a couple of problems. fade() uses gen~ expressions, which means in gibberwocky.max it can only be used with the dedicated gen~ outputs of the [gibberwocky] object. But as you noted, it seems that gibberwocky is currently hardcoded to try and send messages to Live when the fade end. I can fix that (I think) but getting it to work with params might be very difficult.

If you want to stop sequencers but leave gen~ expressions running you can use:

Seq._seqs.forEach( s => s.stop() )

Seq._seqs basically stores all running sequences. But I’ll add a simpler global stop() and start() functions next time I push to the main website. Thanks for the suggestion!

Thanks @charlieroberts.

I’ve got .line working over here with a corresponding .stop message after the fade so all good.
And thanks on being open to the global stop idea!


Recently started diving into Gibberwocky and totally loving it, I’ve been using Max/MSP and Live on a daily basis for years now and it feels so refreshing to have access to things such as LOM and gen~ via code, the syntax is also way more appealing to me than the Haskell-y form of Tidal.

On the other hand, I was wondering if there’s any way to customize the editor (things such as cursor behaviour - I believe it’s by default set on emacs mode - and theme or keymaps). I did try to get into the Atom package but am having some difficulties to get it running on Mac OS Mojave 10.14.6 (I know this is not the right thread to talk about this) and I find the local editor to be so cool anyway. I was just wondering if there’s any way to make the typing enviroment a bit more personal (that’s the only reason why I’d be looking into the Atom version).

@charlieroberts congrats for creating such a cool platform and integration, not detouring too much from my daily tools makes my live-coding(-ish) practices way more useful and intriguing :slight_smile:


Thank you @Ste_v ! glad you’re enjoying it.

I totally understand the desire to use your own editor / personalize the editing experience, and I wish the Atom plugin worked, but I don’t think the project-owner has done anything with it in quite some time.

But you can add your own key commands like so:

Gibber.Environment.keymap['Alt-N'] = ()=> tracks[0].note(0)

If you’re looking for something like vim mode, I could add that in; it’s in gibber so the port is fairly easy. If you want to try the theme system in gibber (a tiny wrapper around @neauoire’s awesome theme work) and see if it works for you I could potentially add it to gibberwocky as well (although it’d be a bit more work): Gibber

Can you describe the cursor behavior you’d like control over?


Hello @charlieroberts and thank you for your reply!

Thanks about the hints for keymaps, that seems easy enough for me to try.
Please don’t wrap your head around themes only for my request, that’s purely an aesthetic thing I’m used to when working in IDEs and editors: some Atom themes for instance provide a clear color coding that makes easy to scan the code a bit more quickly that the current gibberwocky editor, but it’s not something preventing me from enjoying the coding experience (the graphs on the screen are an amazing feature!).

Regarding the cursor, I’m simply more used to the ‘line’ styled cursor that doesn’t highlight the character in full (the emacs/terminal style cursor makes it a bit counterintuitive for me to instantly understand where the next typed character is gonna fall exactly - especially when editing already written lines of codes, like adding square brackets in sequence block where there werent before) but again, it’s just a personal aesthetic habit I got used to :slight_smile:

I take the chance to ask you a couple of questions:
1 - the online editor doesn’t seem able to connect to gibberwocky when in maxforlive, but the local one works fine, just wondering if there’s any drawback from using this version compared to the online one;
2 - is it normal that when editing an already going signal function (ie. a phasor controlling a filter cutoff) the graph gets ‘executed’ as well, resulting in a ~gen doesn't understand p1 error? I seem to have to delete the waveform graph from the line before being able to successfully evaluate that again (the number beside the p in that message increases/changes everytime I re-evaluate the line without removing the graph, the graph freezes and the targeted parameter stops receiving its message); Also, I found myself in the need of evaluating the function line twice in order to have it to change while already going (the function is going, I edit it -removing the graph- and evaluate again, it stops, evaluating again resumes it with the new parameters). Hopefully this makes sense…

I can’t really try to replicate these issues in the online editor since I don’t manage to get it to connect, I’m sure it’s me who’s missing something. I installed all the required packages and am using Brave as web browser - which is based on Chromium and is the same I’m using to run the local one.

Thank you in advance for your help :slight_smile:

Hmmm… in regards to number #1 the /burble editor at works fine for me (discourse keeps replacing the link text, here’s the actual link using /burble,: Gibberwocky)

I’ll have to investigate #2. First, can you confirm you’re using /burble? Thank you!

1 Like

I can’t manage to get Burble connected to maxforlive, so everything I wrote before is referring to the local editor launched by opening the index file in the gibberwocky source folder…

Just to clarify (and see if I’m missing something), the steps for correctly using gibberwocky are:

  • install gibberwocky package via Max/MSP package manager;
  • install the worldmaking package via Github;
  • Put gibberwocky_master.amxd on master track and gibberwocky_midi.amxd on any MIDI track I’m interested in controlling;
  • click either on or local in the master instance to access local or online editor.

Hopefully I’m just missing some steps somewhere and it won’t be hard to debug :slight_smile:

edit - opening up gibberwocky_master.amxd in editor I received this error in the Max console: ws failed to create server: Underlying Transport Error that got me thinking that the issue could be caused by the fact that I’m using the Ableton Live bundled version of Max (I have it set up this way for working purposes). So I tried to switch to the standalone Max version but Burble is still unable to connect. Also, looks like in gibberwocky 1.21 the device is not frozen

edit 2 - Ok! I managed to sort out the issue with Burble, it was due to Brave’s strict integrated protection protocol, which was preventing the browser from getting any communication in and out via websocket. Looks like disabling the block for the editor’s page is enough to get it going. Glad to refer that I can’t reproduce most of those bugs in Burble, which is cool, but I still keep seeing graphs freezing and that p error thing! Personally I’d love to have them ‘fixed’ (or ‘verified’ - maybe is just me getting something wrong in there, but the same code works better in Burble) in the local editor as well :slight_smile:

1 Like

Ahhh, good to hear about /burble!

Getting it fixed in the local version means updating the Max package, which means involving my partner on the project and a more drawn out process in general. Maybe if I can replicate / fix this bug you’re having now it will make more sense to start that process.

Updating /burble is just a drag and drop, so fixes tend to go there first.

1 Like

At the moment the main issue hindering my use of gibberwocky is present in both editors. I’m having problems while re-evaluating lines of code controlling gen~ functions (this is what throws out the error in the screenshot I guess). When evaluating a control function - for instance track[0].volume(mod) where mod is assigned to a phasor(1) - for the first time, everything is cool and I can see the graph popping out and showing me the signal. If I then decide to sequence phasor frequency like mod[0].seq([0.5, 1], 1) and evaluate this line, nothing happens (therefore I guess I have to go back to the track[0].volume(mod) line and evaluate that again. If I revaluate the line, I get an error telling me something like the graph being not ‘accepted’ as parameter and I have to delete that before re-evaluate (and to re-input the very latest ) which got deleted when the graph instanciated before). Re-evaluating the line I see a new graph popping out but it’s either empty or displaying a still 1 or 0 value. The automation is also not received correctly by the controlled parameter. In order for it to work I have to delete the graph again and re-evaluate the line. It’s also natural for me to think that changing the signal values outside of that very specific control function should be enough to change its output and the waveform displaying on the graph.

Doing few researches I have found nothing related to this issue and I’m afraid I’m the one who’s doing something wrong, but can’t really figure it out… I tested against this issue on either Brave and Safari without success.

Thank you so much for your help!

@charlieroberts after a bit of further investigation I can add another detail to the graphs behaviour. Looks like they freeze only if I re-evaluate the line of code with ctrl and not with shift. Hope my report is making sense :slight_smile:

Hmmm… this doesn’t happen for me. The frequency of the phasor alternates successfully and the inline visualization correctly shows the state. I’m using the following code:

mod = phasor(1)
tracks[0].volume( mod )
mod[0].seq([.5,1],1 )

… executed line by line with ctrl+return, and everything works as expected. Can you verify that those three lines of code work for you when executed the same way? I’m not sure what the problem could be here… I’m using the editor at /burble.

1 Like