Problem file!
Can someone open my patcher and try and see what is wrong with it… i kept getting stack overflows (everything was ok though) so i guessed Max had bugged out again, saved and then tried to reload the file. Max now just crashes when trying to load the file, can someone try and see what the problem is?
The main file is "sequencer_basics_01" and the sub file is "SEQ_UI_TICKS", also… the sub-file opens an old version even though the last thing i made max do was save it! :S
The link: http://slcrinkle.googlepages.com/Sequencer.zip
Note: this may be the fastest download 56k modems will ever have, being as its just 3kb lol!
It isn’t a bug…..it’s max being polite and telling you nicely that you are creating an overload of data rather than freezing and crashing……..you need to read through the help files of the button and comparison (, = isn’t doing anything but triggering the button no matter what input it gets. Of course, the button then triggers output from the message box, which triggers the output of integer and so on……… If you want the button to trigger only when the input is greater than or equal to the no_of_rows, you need to use select.
These basics of how max works are really important, you will find reading the first tutorials very helpful for these kinds of problems. They do explain everything.
hold shift+apple on mac or shift+control on windows as you open your original patch and it won’t crash….then read the tutorials and fix the data loop(s)
When you get the stack overflow you can click on the warning in the max window and then press the left-pointing arrow at the bottom and it will highlight the affected objects in your patch. In this case the loop is in the SEQ-UI-TICKS subpatch. When the "row" number box gets sent the 1 from [receive ticks] and that is >= the value from [receive no_of_rows] it will trigger the number one again and again in the same cycle which max can’t cope with. I’m not entirely sure what you’re trying to do so I can’t point out a solution, hopefully you can see where and why the stack overflow is happening though.
lh
Thanks for the ctrl+shift tip, i thought my file might have been corrupted by max!
IRT: "so in your patch, the >= isn’t doing anything but triggering the button no matter what input it gets."
I know how a button works, but i was under the impression that the [>=] or any other comparison would output either a 1(true) or 0(false) statement. Or is it that [button] is triggered even by 0′s?
If it’s the second then i need to make room for a [select 1] object yes?
Yes it is obviously the second…. i see myself making that mistake many times in the future! :<
Ok work on this sequencer program is going pretty well but i’ve come across something i cant seem to beat…
The playmode / drawmode buttons currently flip the g-switch once each press, which is fine, unless you press the same button twice, i’m wanting them to only send the messages if the tables selmode is not what they would set it to. I thought i almost got there before, but i was using about 25 objects and it still wasn’t working.
On a slightly unrelated note, is there anyway to make the table output empty cells as 0 rather than totally ignoring them? So that:
[1][ ][ ]
[1][ ][ ]
[ ][1][ ]
[ ][ ][ ]
becomes:
1 0 0
1 0 0
0 1 0
0 0 0
instead of
"1"
"1"
"1"
" "
?
I have to admit I really don’t know details about jit.cellblock. Is it really the easiest and most versatile way of making your sequencer? If you plan on using it as kind of a bank of toggles which can be read through to get an on/off state for playback of samples its probably much simpler to use other objects for the interface. But that may not be what you have in mind, I’m not sure.
When you click on a cell, the far left outlet isnt telling you the state of all 3 rows, but rather the column/row co-ordinates of the cell you just clicked on.
You might want to have a look at matrixctrl for some ideas.
Btw, you still have a stack overflow occurring in the same loop of objects.
Firstly it is better to use [gate] than [ggate] as it reduces the amount of ui redrawing work your patch needs to do. If you look at the helpfile for both these objects it states that sending a specific number will open the related outlet. Here’s an example. Also, could you post an example of your [table] problem as there isn’t one in your patch.
lh
I would suggest that you don’t use [jit.cellblock] as your data storage. Use [coll]. Jit.cellblock is ok as an editor to write into the coll, but I wouldn’t use it real-time. Not only is it not the best Max object ever, it’s also a GUI element, which means it’s relatively slow.
I solved my gate problem! Just made the selmode choices make numbers (3 or 5) and then -3 from that so the output is 0 or 2, 0 sets it one way and anything else is obviously treated as a 1.
However now i’m trying to fill the table with zeros, and that doesn’t seem to be working. The uzi objects don’t appear to be working right: the first one which picks the row works fine, but the second one only outputs the argument given it, not a count up to it. Does anyone know where i’m going wrong?
Also the stack overflow should be gone now, it was just a simple matter of a few missing loadbang objects.
As for why this is a database, working as you can see i am, with drums, simple 0′s and 1′s would work well, but eventually i want to make this into a sequencer for music too, with proper note references "c-2", "d#5", "g#3" etc, so i’ll need it to be text based, otherwise, yes i could probably settle for using [coll] and [pack] objects.
The problem with the uzis is that the first uzi is causing the pack to output, and then the second uzi sends a 1 and then a 2 to the second inlet of the pack, which doesn’t really change anything since it doesn’t trigger output. So the first time you run the patch after opening it, the second item of the list will be 0 (since it was initialized to 0 by pack and hasn’t yet been changed by the second uzi), and every time after that it will be 2. It will never be 1 because the pack is not outputting the list during that time. The simplest way to solve this is simply to switch the inlets that the uzis are connected to. That way, the second uzi will cause the pack to output the list every time the value changes. When uzis are "chained" in this way, it is basically like nested for-next loops, and the last uzi is the innermost loop. Of course, once you make the change, the column number will be first in the list, so you will need to reorder it somehow or just switch the uzis so that the first one outputs the column number.
Ok now i know i’m not doing anything wrong here:
This big spiderweb is the equivalent of a "for – next" loop, except it doesn’t want to be. It should count up to 29, (in "actual number" box) as it should increase until its not less than thirty, however, by some unknown law of max, it just stops after the first loop. Does max believe that 0 is greater than 32???
Actually, you are doing several things wrong. You need to read or reread the "Message Ordering" tutorial. It does take some time to grasp this concept. If you initialize the < object with any number greater than 0, you will get a stack overflow, and the only reason that isn't happening is that the < object defaults to "< 0". The "actual number" box is outputting its value to three different places - although the button is superfluous and probably isn't helping the situation. Nevertheless, the number box outputs its value to these three places in right-to-left order. But here is the key: when it outputs its value to the < object, it will continue downward along that chain of objects until it reaches a stopping point (meaning that output in that object is not triggered, or at least that it is delayed; e.g. pipe or "non-left" inlets of most objects). Only when it has reached this stopping point will it go back up to the original fork and go to the next object (in this case, the button). If you follow the first chain of objects in this patch, you will see that they are connected in a loop that contains no stopping points, so the "actual number" box's value NEVER gets to the message box, so it never increases. So in the first iteration of the loop, the "actual number" is -1, and in every other iteration it is 0 (-1 + 1). So you have an infinite loop because it is constantly testing 0 < 30. And that means stack overflow.
But really, why not just use uzi? It does what you are trying to do.
Uzi doesn’t seem to work, i’d eventually have to use two. one for each row and one for each column, as they only fire "as quick as possible" the first one (say the row_number) might have advanced to the next row before every box on the column is filled in.
It seems what your saying is [< ] is completely useless, in that the number in the left inlet (what is tested) HAS to be below zero? Don’t mean to be rude, but that’s crazy! If i dont have the [<] right, it’s because it’s help file is wrong. At the top of the [<] objects help file it says:
"< takes any given number, compares it to another specified number, and outputs a 1 if the number is less than the comparison-number or 0 if it is greater or equal."
So what should be happening is that "actual number" (left inlet) should be being tested for whether or not it is less than 32 (right inlet), 0 if not, 1 if so. The select below that stops the loop from going past the point of no return. I’ll carry on though, and see if i can find the right combination of things that it likes, theres got to be some….
No, uzi does not fire "as quick as possible." It follows the same message ordering rules that I described in my last message: It outputs the index, then waits for the subsequent objects to get to a stopping point before outputting the next index. It does this in a consistent and deterministic way, so it is entirely appropriate for use as a for-next loop (provided the objects are connected correctly). Your previous example (with the two uzis) had a very simple problem with a straightforward solution, so you should probably continue down that path.
Of course the < object can be used with positive values. It compares the left inlet value with either an argument (e.g. "< 30") or with the right inlet value (which overrides the argument or the default value, which is 0). But just because a number box is connected to the right inlet doesn't mean that the right inlet has received that value. If you want the number box to send its value automatically, use loadbang.
Trust me, learning Max will be a lot less painful if you assume that problems with patches are caused by errors that you have made, rather than assuming that Max is crazy, buggy, illogical, or overly picky. Would we all be using it if it were?
Never mind, i eventually solved my problems, the end result is a rather snazzy little drum masheen! Here it is:
Wow thats quite long, and filled with spelling mistakes according to firefox. You’ll need some drum samples (or any sort of samples!). But it works!
| Crinkle wrote on Wed, 29 July 2009 19:05 |
| It seems what your saying is [< ] is completely useless, in that the number in the left inlet (what is tested) HAS to be below zero? |
Okay, I see now why you thought that. When I said "If you initialize the < object with any number greater than 0, you will get a stack overflow," I meant just in this particular patch, not in general. Sorry for the confusion.
I still get a stack overflow when using your new patch, it occurs in the same place as before. Have a look at some of the max tutorials that explain how the order of execution can affect your patch. You could also look at using something like [matrixctrl] instead of [jit.cellblock] for programming in your rhythm. It’s my go-to object for step sequencing.
lh
Thats the only thing that annoys me about max, it doesn’t reset everything (as if first loaded) untill you quit and reload max entirely. So i can work on my patch, which worked well for me, thinking its fine and dandy, and then come back to it and it’s broken.
Can you please point me as to where the overflow occurs? I don’t have a clue, and the program is now rather complicated!
I’ll have a look at matrixctrl but it looks like it only deals with on+off states, good for drums which dont need to be programmed in pitch, but seemingly impractical where each bit would need to record pitch too!
It was the 0 message on the far right of your SEQ_UI_TICKS subpatch that caused the stack overflow just like last time. As for [matrixctrl], it has a "range" attribute where you can set more states. I’ve used it with 127 to send MIDI velocity values. You might want to use a customised image file though as it can help make things clearer. Here is a small example of a MIDI synth I threw together previously. It should show you how I use [matrixctrl] to get data, this one only has 4 velocity levels but as I mentioned you could increase it in your patch.
lh