• weightless

    @solipp Oh I see, yes that makes sense now. In fact I think it's more useful this way precisely because it works like initbang, and if you need to send stuff to the parent patch you can always do it with loadbang.

    I have added some more abstractions for saving arrays and text which are in the parent patch, this should cover pretty much everything I think.

    store.state1.2.zip

    posted in abstract~ read more
  • weightless

    @solipp Very nice, thanks!

    posted in abstract~ read more
  • weightless

    Doing some more experimenting with the savestate object to save parameters which are not in an abstraction but in the parent patch, it seems that there is some odd behaviour in that when the patch is loaded and savestate receives the lists, they are available inside the abstraction but cannot be sent out to the parent patch directly via outlets, I wonder why that is. This is shown on the right hand side of store.state-help.pd.

    store.state1.1.zip

    posted in abstract~ read more
  • weightless

    @solipp No worries, I can see it's not very intuitive. Given the object's very limited documentation this is the most modular solution I can think of. I would be very interested to see some alternative uses.

    posted in abstract~ read more
  • weightless

    @Jona The main difference with the flags is that if you have an abstraction with the object [array define -k ..], the same content of the array is saved for all instances of the abstraction, whereas [savestate] allows you to save different values for each instance.

    I can imagine some problems using the init option for sliders/toggles/radio etc and savestate at the same time, since those init values would override the savestate. For loadbang, Miller's trick is probably enough, but for init I wouldn't know. Probably best not to use it at all?

    posted in abstract~ read more
  • weightless

    @solipp Maybe I'm missing something but as far as I can see, [savestate] just saves a bunch of lists to the parent patch and links those lists to the instance that sent them, so that when you open the parent patch again each instance of the abstraction gets back its respective lists. But there is no built-in way to associate each list to the corresponding parameter, and whenever you open the parent patch each instance of [savestate] that you have in there receives all lists relative to that abstraction. How do you parse those saved lists? I think you have to either pack/unpack your parameters into a single list like in the help file, with each element of the list being a single parameter (which doesn't seem practical to me, especially if you want to save variable length arrays and text), or you can create one list for each parameter, but in that case you need to attach some sort of identifier to each list so that you know how to parse them. Something like this:Screenshot 2019-05-19 at 21.51.43.png
    Which is exactly what I did, except that by making abstractions for this mechanism you don't have to copy/paste/rename it every time you add a new parameter to your abstraction.

    Am I missing something? How is everybody using this object?

    posted in abstract~ read more
  • weightless

    Hi everybody,

    Pd 0.49.1 has a new object [savestate] for saving lists of parameters to the parent patch so that different instances of an abstraction are saved with different parameters. The help file for it shows a method of creating/unpacking the list which I think is a bit awkward for abstractions with lots of parameters as it requires a lot of patching and is dependant on the order of packing/unpacking.
    I have adapted the method used for saving presets to a text file to do the state saving in a very similar fashion here. Store.state-help.pd explains its workings as well as I could, hope it's clear enough.

    store.state1.0.zip

    In the future I'd like to merge this method and the text file preset saving to work alongside (where the presets are just multiple states, basically), but for most purposes I think the state saving is more useful and immediate than presets. At least for me, anyway.

    This new object opens up interesting possibilities so any feedback or alternative methods are welcome.

    posted in abstract~ read more
  • weightless

    @solipp Thanks.
    [savestate] looks like a nice addition, I had a quick look and it seems more basic than I hoped but at least gives us something to work with.

    posted in abstract~ read more
  • weightless

    @solipp Thank you for sharing this, it's very helpful. I didn't know about [savestate], at last!

    posted in abstract~ read more
  • weightless

    @dbts I'll add to the discussion the two ways I did it:

    [f2scale] remaps the input float to a scale chosen from a list, you specify the scale name and the base midi note. I find this is handy for standard scales (I found the included scales on some website somewhere, I'm not sure they are completely accurate), but you can add your own custom ones at the end of the [text] object.

    [subset] is simpler and just quantises to a specified list, you can provide the list in the arguments which I find very practical. I made it to use with other abstractions for alternative equal temperaments and just intonation tunings, but I guess it's helpful on it's own too.

    f2scale_subset.zip

    See the relative help files for how to use them (the other abstractions are just used in the help files).

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!