[mlrv 2.1] preset bug drive

  • Hi % / galapagoose,

    Loving the program, but still struggling with presets to work on my machine (Win 7 64bit, latest Max Runtime) so I thought I'd try and offer my help in debugging it. The following steps lead me to believe that the problem is almost entirely at the preset loading end. If you would like me to run any simple tests/patches for preset loading on windows please let me know.

    Getting presets working is the only real thing stopping me for gigging with mlrv so I'd love to help you guys get this sorted. Other Windows/Mac users with similar preset issues might care to repeat these steps and see if saving/loading are working correctly.

    === Step 1: Initialisation ===

    After opening mlrv blank, I saved a preset called "before.json". I then made the following changes to the default patch:

    * Loaded 8 files, 7 mapped to rows
    * Set the first six rows to have 1 group each
    * Set the last two rows to play samples in reverse
    * Set row 2 to have OCT 1
    * Set row 3 to have OCT 2
    * Set row 7 to have GAIN full
    * Turn off quantize
    * Changed "tempo" from 100 to 130
    * Changed "next tempo" from 100 to 87
    * Mapped keyboard keys 1 to 4 to mutes 1-4
    * Delay
    * Changed delay LPF from 310 to 500Hz
    * Changed delay HPF from 7165 to 5959Hz
    * Changed Delay time to 3
    * Changed all volumes/aux sends to about half
    * Changed sound card to asio drivers
    * Changed preset name to "bugtest"

    Click Save As (saved to "after.json")

    === Step 2: Saving ===

    Open up "after.json" to examine what has and hasn't been saved. The file contains two sections id 1 and 2. from my understanding 1 is for global settings and id 2 (and presumably 3, 4, ...) are for individual sets?

    **Settings saved to the preset file in slot id 1 (name "preset")**

    - The paths of the 8 files stored.
    - DSP device appears to be saved ( line 907 device changes from number 1 to 3)
    - Keyboard mappings to mutes (though not any custom ranges)

    **Settings saved in slot id 2 (name "bugtest")**

    - Which sample is mapped to which row (with correct steps, speed, octave, gain, reverse, transpose settings)
    - Delay parameters (freq, delay sync)
    - Volume and send levels
    - Keyboard mappings to mutes (though not any custom ranges)
    - Next tempo, current tempo (default values in the id 1 section
    - Quantize

    **Misc Differences**

    line: 2085
    **before**: "[setup-over]::5grpcol[1]" : [ 0.6, 0.79, 0.95, 1.0, 0.576471, 0.760784, 0.776471 ],
    **after**: "[setup-over]::5grpcol[1]" : [ 0.6 ],

    There is no "[setup-over]::6grpcol" - is this deliberate or a typo?

    Conclusion is that saving is working more or less correctly (save custom range of values for mapping).

    Exit Max completely.

    === Step 3: Loading ===

    After I try to reload "after.json", the file open dialog reopens (as if something didn't work maybe)? On the second attempt the dialog closes. The following messages appear in the Max Output window:

    pattrmarker: pattrmarker: name /mixer/6grp/vfader already in use
    pattrmarker: pattrmarker: name /mixer/6grp/sfader already in use
    pattrmarker: pattrmarker: name /mixer/6grp/mute already in use
    pattrmarker: pattrmarker: name /mixer/6grp/route already in use
    pattrmarker: pattrmarker: name /mixer/6grp/stop already in use
    pattrmarker: pattrmarker: name /mixer/5grp/vfader already in use
    pattrmarker: pattrmarker: name /mixer/5grp/sfader already in use
    pattrmarker: pattrmarker: name /mixer/5grp/mute already in use
    pattrmarker: pattrmarker: name /mixer/5grp/route already in use
    pattrmarker: pattrmarker: name /mixer/5grp/stop already in use

    None of the settings are recalled apart from the keyboard mappings (but no custom ranges). Preset name (in this case "bugtest") **is** loaded however.

    So basically it seems that saving is working fine but loading is not. I've tried to poke around in the patch put my experience of pattr is very limited and it all seems a bit daunting! Attached are screenshots / preset files for reference.

    Hope this has been of some help, Hemmer

  • Thanks for your work. I too am hoping this gets sorted out. I have a similar set up, if there is anything additional I can do to help let me know.

  • +++

    agreed, thanks for pulling this together! we'll take a look 'n see if we can work a fix into the next release.

  • just as a quick test, can you try something....

    1. open up mlrv (a blank set)

    2. click 'load' and open "preset.json"

    then repeat the above steps. i have a feeling that the default settings are not getting properly loaded when the application boots and as such you don't have some of the essential settings saved in your file.

    let me know if this changes anything?!?!

  • im gonna try this today as im playing later! thanks for the tips gala ill let u know

  • @galapagoose just tried loading "preset.json" first and it didn't change anything (at least that i could see). the settings saved in the file "preset.json" are the same as that of the default patch though (tempo, quantize etc) so i wouldn't expect to see a difference?

    t also didn't affect the result of following the set of steps above, i.e. the loading stage didn't work for me.

    i have also just tried the above on WinXP SP3, with exactly the same results.

    **note:** the preset name actually **is** successfully reloaded so it's not that the file just straight up isn't being loaded.

  • no joy for me here either, clips do remain in the drop down but aren't selected on opening.

  • same prob above as hemmer/dean (I'm also on XP sp3)

  • sounds like some weird windows jazz to me... i'm afraid to say i have absolutely zero access to a windows machine in my current adventures in NYC. are there any max coders that know of differences in how pattr is handled across platforms?

  • @galapagoose: i'm pretty keen to get this sorted so i will try and have a stab at fixing it myself. can you provide a (detailed?) overview about how the preset system is currently set up. stuff like which patchers deal specifically with preset stuff, how pattr is intended to interact with the json files etc - the more detailed the better. if you post the details in this thread then I guess other max programmers can have a go too.

    also if you have any really simple stripped down examples of pattr / json interaction that you would like me to test that would be great - i.e. a patch which just saves one parameter and then recalls it?

    thanks, hemmer

  • you'll need to look in the main mlrv.maxpat file. the bottom left corner is all of the pattr system, all centered around the [pattrstorage preset.json] object. everything is based around 1 save file which is the preset.json file that is included in the package. the load/save/saveas buttons just update and reconfigure which file the patch points towards.

    the [preset.maxpat] file handles preset management and prepares settings for saving. it doesn't have much to do with loading (just populates the preset names list).

    there are 2 tiers to the system.

    1: a set of global parameters that are recalled on first load of the application or any time a new save-file is loaded. these include the file-list, default mixer settings and tab-settings (amongst other things).

    2: the per-preset setup which focusses on settings per row, mixer settings, next tempo etc.

    in the mlrv patch:
    p [pattr]edit — autostores any changes made to the setup panel or the setlist and updates the save file directly (you still need to hit 'save' though)

    p presets — the left section is per-preset handler (only loads settings as necessary), the middle and right sections handle global settings and should only happen when a new file is loaded / saved.

    regarding a pattr run-through — maersk made a great primer on using the pattr system which is on the wiki. i'd recommend making sure you can get that to work on your machine first before diving into the super complicated mlrv setup.

    there's always a possibility that one of the commands i call into pattr is broken for a particular windows setup, but it's of course very difficult to ascertain without having such a computer at the ready. please do let us know how you go!

  • Actually i have never had luck saving presets in any version of mlr on windows? Thats why I switched to molar for a bit. Then when mlrv 2 was coming I was like YESSSSSS maybe this will do the trick....... :(

    I wish i could help get this working in some way. Hemmer let me know if you have some fixes that need testing.

  • excellent thanks very much. think the first stage will be seeing if the data is actually getting loaded into max at all before getting too involved with the pattr stuff.

    please other windows folk get involved too if you can, not promising anything magical myself. more eyes the better and that sort of thing!

    Interestingly there is a report of it not working on a mac too, but possibly a different issue: http://code.google.com/p/mlrv/issues/detail?id=39

    EDIT: wiki link for the pattr intro is http://docs.monome.org/doku.php?id=dev:max:saving

  • yo --- you can check if the files are being loaded properly by clicking the 'storagewindow' message box attached to pattrstorage. scan through that dropdown and see if the presets are loading properly. i can take some screenshots of what you should see.

    this is looking directly into the pattrstorage to see what is loaded so you can check if the file is actually loading properly and being lost in the system, or if there's something up with the files themselves...

  • //ok interesting. the following error seems to be at the crux of the problem:

    pattrstorage: error reading file at byte offset 0 / not well-formed (invalid token)//

    **EDIT: ignore the above (xml / json confusion from my outdated version of max)**

    As the .json file is completely valid and not corrupted in anyway i suspect that the pattrstorage object is not getting the filename properly.

    Good news is that I've tried the pattrstorage example in the max help and it works fine, so the method should work eventually.

    I think it has something to do with the fact that the open file dialog opens twice, that didn't happen in the example. I think I'm getting somewhere, just trying to get my head round it all!

  • ohhhhh ok.

    it could well be to do with the [mxj] object which determines whether you are loading a .json / .xml / .mlr or a no-name extension. maybe try plugging a 'load' message directly into the pattrstorage and see if you can get that to load your set?

    if that's the case then i'll see if there's another way to determine the file-extension to avoid the issue. i'll create a little mxj tester for you to try and see if that's the problem element.

  • just to check if you bang a "read" message to the red pattrstorage object in the main patch, a dialog opens (once) and the data from the json file you read in gets imported (viewable by clicking on the pattrstorage object)?

  • that's the idea!

    also;;;;;; when you load the patch as it's unzipped from the download, do all the mappings load properly or is the mapping tab empty?

  • ----------begin_max5_patcher----------

    try this and let me know what happens when you load your save file.

  • unzipping the patch as is, it actually load preset.json fine! confirmed by switching the mappings for the pattern buttons by manually editing preset.json. interesting...

  • i don't think the issue is with file extension recognition though. that part was just me getting confused by using an older version of max which was saving as xml rather than json.

    i managed to very loosely get a preset to load (hurray). by rewiring the "load" button directly to bang a read message to pattrstorage, it can load the settings in. then banging a "2" message, I could load the preset specific settings (files mappings, speed reverse etc). the general (main) preset settings aren't loaded though so something's still not quite right but its a promising start.

    i definitely need sleep now though - nothing is making sense anymore. thanks for your help so far.


  • i wish i could help with this but ive no idea with max unfortunately.

    Thanks hemmer for working on it.

  • right, been playing around a bit more.

    if I send a "read" message to the red [pattrstorage preset] object, the open file dialog opens and i can load a preset first time.

    doubleclicking on the [pattrstorage preset] object, it seems like the system information has been loaded for the first slot (id 1) - e.g. the filepath list is in there. however it doesn't seem to get loaded past this point and doesn't get applied to the actual objects in the app, e.g. in the file dropdown list, filepaths aren't listed.

    banging a message "2" loads the details of the first preset into the pattrstorage object. again by double clicking the pattrstorage object, i can see that all the settings (tempo, speed etc) are correct. this time, the settings are also applied to the patch: group settings, speeds etc all update on the screen. this also works for further presets.

    one bug that i have spotted (though it may be due to my debugging!) is that each time I switch preset (by banging a message with a number), the following errors appear in the Max Window:

    pattrmarker: pattrmarker: name /mixer/6grp/vfader already in use
    pattrmarker: pattrmarker: name /mixer/6grp/sfader already in use
    pattrmarker: pattrmarker: name /mixer/6grp/mute already in use
    pattrmarker: pattrmarker: name /mixer/6grp/route already in use
    pattrmarker: pattrmarker: name /mixer/6grp/stop already in use
    pattrmarker: pattrmarker: name /mixer/5grp/vfader already in use
    pattrmarker: pattrmarker: name /mixer/5grp/sfader already in use
    pattrmarker: pattrmarker: name /mixer/5grp/mute already in use
    pattrmarker: pattrmarker: name /mixer/5grp/route already in use
    pattrmarker: pattrmarker: name /mixer/5grp/stop already in use

    examining the mixer section of the data in the pattrstorage object, there are multiple entries for the 5&6 groups:

    grp5, grp6, grp5[1], grp6[1], ... , grp5[n], grp6[n], ...

    more get added for each time the preset is changed.

    probably connected - i am still concerned by the 5grpcol[1] entries in the [setup-over] section of the .json file - surely this should be 6grpcol? maybe a simple copy&paste type error?

    hopefully some of this may be of use, if not my next stage of reasoning is to look at the [fileformat] and [pattr-save] subpatches, neither of which are making any sense to me as yet (any pointers would be great).

    cheers, hemmer

  • ok:

    simply reading in a new file won't be the same as hitting the existing 'load' button. this is because the pattr system loads certain settings when a new .json file is loaded (eg. midi mappings, file-list etc.) and then when you change preset only certain information is updated.

    the reason for this approach is (a) i couldn't figure out how to have multiple instances of pattr co-existing in a logical manner, and (b) updating all the params every time you open a new preset would cause about 12000 object updates and make a big gap in the audio stream, not to mention shooting your CPU to 3000% capacity.

    at the moment, i'd ask we confine the preset bug drive to a 4group setup. the 6group support is still experimental, and obviously has some issues -- such is the nature of dynamically adding/deleting new objects in max.

    in terms of how the patch should load, i'll try and define the 2 stages a bit better:
    firstly, when a new file is loaded, the filename is parsed by the [p legacyformat] patcher which determines whether the file is a .json or an older format. let's disregard the old formats for the moment, and focus on the .json section (it's a whole lot simpler).

    okkkkkkkk:: just realised why the double-contextual menu thing was happening!!! turns out the first one doesn't actually do anything if you select a .json file. you'll need to select the json file twice in order to properly load it.

    anyway - the [p fileformat] patch sends a 'read' message to pattrstorage and opens the selected .json file. once the file is loaded pattrstorage sends a message "read [filename]" which is parsed by the route object below and sends the filename to [s [file]name]. this message is sent to preset.maxpat which populates the list of preset names. it also sends back up to [p presets] (just above pattrstorage) and triggers some messages:

    1. recalls 'grid::patcher' which is the name of the patch which holds all of the filepaths for your samples. this causes the filenames to be loaded internally into the 128 pattrs in the grid.maxpat patch (each pattr holds 8 filenames)

    2. a bang is sent sequentially to all of those pattrs via [s [path]restore] which makes each filepath pattr shoot out it's contents to fill the copies of [poly~ file_poly] with sample info. [coll sample_lookup] then creates a list of all the samples.

    3. 'recall 1' is then sent to pattrstorage which loads the default settings in the first preset (which is where mappings + mixer levels + tab settings are stored). this is all your getting when you send a number message to pattrstorage

    4. a bang is sent to [s [map]loadtrig] which tells all of the loaded mappings to generate their own namespace and send any currently existing mapping to the MAPPING.maxpat tab which populates the mapping list (with the saved range)

  • okkkk -- now onwards. when you change presets, instead of sending a simple number message to pattr, you need to use the preset-load mechanism in order not to break the system..... here's the process:

    when you choose a preset-name from the dropdown or click next/previous:

    1. in preset.maxpat, in the [p pre.int] subpatch: the preset number (first preset is 2 — 1 is hidden as it only holds default values, and 0 is not saved with the file) is sent to [s [pre]p.recall] which tells all the ch.maxpats a new preset is about to be received and prepares for that.

    2. time.maxpat loads the new presets tempo into 'next tempo'

    3. in the main patch [p presets] receives the new preset number and triggers a number of settings to be loaded per preset, in order:
    • mixer settings are recalled (fader levels etc.)
    • row (ch.maxpat) settings are recalled sequentially and only as many as are displayed in the interface
    • pattern recorder lengths are recalled
    • nexttempo is recalled

    that is all — no mappings or filepaths or anything of the sort is recalled at this stage.


    hope that helps you understand roughly how the pattr system works and can help us find the solution to all of ze problems. i'm going to fix up the double-load-menu issue now that i've realised why it's happening!

  • ok cheers, plenty to be getting on with (plus good idea about keeping it to groups 3+4)! if you want, you can send me a version with the double-load thing fixed i can at least check if that was what the problem was, although it's probably deeper than that...

  • I spent a couple hours on this and didn't get very far sorry to say. I've been trying to focus on why the samples aren't being assigned to the channels on load.

    In grid.maxpat, [coll sample_lookup 1] is being correctly filled with the file names so we know the JSON is being read correctly. However, if you look at ch.maxpat's [p edit] sub-patch, nothing is coming out of [pattr @bindto parent::filename] when the JSON is loaded.

    I'm actually a little confused as to how parent::filename is being used because the parent patch (ch.maxpat) doesn't have an object called filename. I'm pretty ignorant in the ways of the pattr though so I'm probably missing something.

  • the umenu that displays the name of your selected file has the name 'filename' (look in the inspector). it's then discovered by the autopattr object which creates a reference.

    we don't expect the [pattr @bindto parent::filename] to output it's contents until a preset is recalled which causes the output to respond.

    i'm tentative to upload the fix for the double-message box as the first file-chooser just sees if the file is a json, then loads another window which only accepts json files. if you select the same json file twice, it is exactly the same as the fixed version.


  • first of all apologies if i seem to be rambling at lot in this thread - a lot of this is new and i'm just trying to give you a verbose picture of what's happening at this end so hopefully you might spot something strange.

    anyway, couple more things i've noticed:

    **mapping**: if i click on "start mapping" then remap the top row (e.g. mm:0:0 - mm:0:3 for group stops, mm:0:4 - mm:0:7 for mutes), i can save this (successfully) to a preset file. however if I open up the file in a text editor these new entries do appear, but the old mappings haven't been deleted, e.g. the original mapping:

    "mixer::aux::param[2]::paramap::mapping" : [ "mm:0:6 0.0000 1.0000" ]

    is also there. because mlrv seems to load settings from the preset sequentially, it loads the new mappings first (as they appear in the file first) but then as it goes through the file these eventually get replaced by the old ones. basically the last version of a mapping to be loaded is the one that sticks. bit of a tricky problem to get around though, you may need to purge all existing mappings before saving the new set? (not sure if this is a windows specific thing but I thought i'd mention it anyway)

    **presets**: if i open a new set, add some files to the filelist and change the mappings and save //without// clicking __store__ first, then when reopening these settings after a restart (ignoring the above bug for now) the are recalled fine. However, if during that process I click store and create a new "tier 2" preset, the main (tier 1) settings fail to load on restart. i'm currently looking into why this might be the case, especially considering in both cases the preset.json has a second section (id : 2).

    unfortunately my dissertation is due in a couple of weeks so i won't be able to do too much until then, but i'm still having a look through it now and then. i'm definitely hooked on cracking this and do feel like i'm slowly getting a better picture of what's going on.

    ramble over, hemmer

  • could this be something as simple as running it in compatibility mode? i wonder if it would have any effect, might try it this evening!

  • I couldn't get it to work with compatibility mode. Are there linked JS files or something that could use different escape characters or something? Has to do with changes made from osx/ win x sample object maybe? I don't know enough about how max/msp works to be very effective.

  • i can't switch off recorded patterns. arghhh!

  • @shmaltz

    (wrong thread btw)

    a short press stops the playback of a pattern

    then either —
    a long press clears the pattern
    or another short press restarts playback of the pattern

  • just a little update:: i was able to do some debugging with makingthenoise's computer down here in austin and have determined a bunch of issues with the pattr system, and differences between mac and pc storage.

    at this stage i don't have a clear enough understanding of the issue to write much about it, but i believe it has to do with sub-patchers not passing on recall messages to nested sub-patchers with autopattr's inside. it could actually be a maxmsp bug, but hopefully we'll find a work around.

    we've got further debug time planned for this week so should hopefully have an update in the next few days.

  • Great news if this can be fixed!

    While testing my new 256 last night, i dropped a few loops of 'trans europe express' into MLRV2, really really great fun, only bummer was knowing that I wouldn't be able to recall it back later.

  • rest assured, any set you construct is being SAVED properly. so make sure you save the sets your creating and you'll be able to load them after the new updates (or at least that's the plan!!)

  • @galapagoose: that's excellent news! i'll keep looking just in case i can spot anything too.

    also did you get my post above about saving all the mappings (and only recalling those which appear last in the file)? //edit:// to clarify, it's the bug where saving only adds new mappings to the preset file, and doesn't remove old mappings. the last mapping it encounters in the preset file for a button is the persistent one.

    it might explain some of the mapping bugs in the other thread.

  • ahhhh that's very interesting — seems to point towards the way mlrv is interacting with the pattr system. it calls parameters by name directly, rather than doing global saves and recalls, so it seems like the way i'm referencing individual settings is not platform independent, or there is something else blocking the connection.

    the mapping issue seems to be about the 'delete' function not editing the pattr storage list properly... food for thought!

    this is probably not the easiest bug to squash unfortunately as the pattr system is so deeply integrated in the patch. hopefully it won't mean having to fork a separate version that works on PC and we can make it platform independent....

  • PROGRESS::::::::::::::::

    thanks to makingthenoise, i've been slaving away on his PC laptop here in boston and have confirmed that this issue is in fact a bug with MaxMSP.

    i've just sent a bug report to the cycling'74 folks and hopefully they'll have a fix for it, though that almost certainly won't be until the 5.1.8 update if not 5.1.9

    so unfortunately for the moment windows file-loading is broken (though indeed your sets are still being saved!).

    if anyone is interested in the bug itself, here's the patch which should work fine on a mac, but break on a PC::


  • great news, impressive work!

  • hrmmm... well i guess it's good news in that we're now on the road to a solution... but not such good news that it works now.... alas!

  • saw a thread on cycling 74 site about pattrstorage problems. maybe you should post your example patch there. some devs frequent the forums. maybe we'll get support from the forum there & help speed a fix?

  • It seems that I might have this problem with board. What is the bug?

  • awesome news that your on the right track!

  • the patch i posted should demonstrate the bug pretty clearly —— just have a good look through it!

  • @galapagoose: good news in the latest max update (5.1.8) the test patch that you posted before now works (it didn't with 5.1.7 as expected).

    nearly everything seems to be working, it's definitely gigable now! there's maybe a couple of issues with quantize and other settings not being remembered but it's probably user error rather than anything serious and i need to have a proper look at it. thanks so much for your help with this one!

  • @hemmer pretty sure quantise is NOT (edit) stored on mac too, great news :)

  • im well glad, this will get me back to working with mlrv!


  • yip, on XP here and in the words of Larry David, 'prettay prettay prettay good.'

    @galapagoose great work finding out this problem, top man!

  • So is preset saving and loading supposed to be working now with RT 5.1.8?

    Mine still won't load anything, I get two load file prompts after each other..Am I supposed to load the same .json file twice? Hmmm

    Win7 x64

  • yeah its doing that for some reason, when you click on the .json file, it opens up that folders available .json files.

    simply yes, select it twice.