cbannis

I am working on a preset manager. A basic preset, in my patch, is now a table of settings in jit.cellblock. Each row represents a track (50 tracks) and each column a setting for that track (file path, level, bus type, bus level etc...).

I also have created an additional table to manage those presets. Its is now a table of preset names and paths to the files which contain the data (again realized with jit.cellblock).

The whole system is a bit clumsy and slow. I am convinced there is a better way. A single preset is approx. a 6k text file when stored to disk. I a having trouble storing the contents of an entire preset in a single cell of a table. Although this might be the way to go.

I am working on a preset manager.  A basic preset, in my patch, is now a table of settings in jit.cellblock.  Each row represents a track (50 tracks) and each column a setting for that track (file path, level, bus type, bus level etc...).  

I also have created an additional table to manage those presets.  Its is now a table of preset names and paths to the files which contain the data (again realized with jit.cellblock).  

The whole system is a bit clumsy and slow.  I am convinced there is a better way.  A single preset is approx. a 6k text file when stored to disk.  I a having trouble storing the contents of an entire preset in a single cell of a table.  Although this might be the way to go.  

preset-manager

well its difficult to tell what approach would be best without gaining a deeper understanding of the patch itself. however, i recommend you look at the pattr objects...

firstly, double check to see if they are compatible with jit.cellblock, or if you can create an abstraction to fetch / set data as a work around.

The pattr route might be more beneficial in your situation as you it sounds like you are dealing with large sets of data.

well its difficult to tell what approach would be best without gaining a deeper understanding of the patch itself. however, i recommend you look at the pattr objects... 

If you check out Jamoma, there's a module (jmod.cuelist) to store 

presets in a text format using OSC to address the various parameters of 

the modules. There's also the possibility of saving presets for each 

module as XML, and pattr-support is integrated.

> well its difficult to tell what approach would be best without gaining a deeper understanding of the patch itself. however, i recommend you look at the pattr objects... 

> firstly, double check to see if they are compatible with jit.cellblock, or if you can create an abstraction to fetch / set data as a work around.

> The pattr route might be more beneficial in your situation as you it sounds like you are dealing with large sets of data.

If you check out Jamoma, there's a module (jmod.cuelist) to store 
presets in a text format using OSC to address the various parameters of 
the modules. There's also the possibility of saving presets for each 
module as XML, and pattr-support is integrated.

justin wrote:
> well its difficult to tell what approach would be best without gaining a deeper understanding of the patch itself. however, i recommend you look at the pattr objects... 
>
> firstly, double check to see if they are compatible with jit.cellblock, or if you can create an abstraction to fetch / set data as a work around.
>
> The pattr route might be more beneficial in your situation as you it sounds like you are dealing with large sets of data.
>
> j
>


I've written an abstraction that you can simply drop into your patcher and start storing and recalling presets using the pattr family. It's called p.storage. You can download it here:

It might be helpful for you, if not to use out of the box, as a starting point for your own patch

I've written an abstraction that you can simply drop into your patcher and start storing and recalling presets using the pattr family.  It's called p.storage. You can download it here:

Thanks for the advice. "pattr" is definitely the way to go. I was sometimes dropping 500ms parsing my preset data with JavaScript. I am still using the jit.cellblock matrix to display the current configuration but the data now lives in a pattr domain. I have given up a bit of control over the formatting but the speed is smokin' :)

I am also twaeking p.storage to present the saved presets in an expanded list view as opposed to a pulldown (thanks pelado this is great!).

Thanks for the advice.  "pattr" is definitely the way to go.  I was sometimes dropping 500ms parsing my preset data with JavaScript.  I am still using the jit.cellblock matrix to display the current configuration but the data now lives in a pattr domain.  I have given up a bit of control over the formatting but the speed is smokin' :) 

I am also twaeking p.storage to present the saved presets in an expanded list view as opposed to a pulldown (thanks pelado this is great!).   

http://www.pan-etc.net/nav/dev/dev-patch.htm