RAYZOON

Many (simple) user actions affect a lot of data, especially due to the non-linearity of many A.I. functions. Saving the entire state is the only efficient/effective way to do this but it is prohibitive due to save time/threading issues. I should also note that the way data is stored in JS is a much more complex process than the floating-point array load/store that other plugins like synths are employing. It is complicated further by a mechanism that allows us easy compatibility between versions, which is very important due to the frequent updates we release. I mention this to explain why load/store is so time-intensive.

Ralph [RZ] wrote:Many (simple) user actions affect a lot of data, especially due to the non-linearity of many A.I. functions. Saving the entire state is the only efficient/effective way to do this but it is prohibitive due to save time/threading issues. I should also note that the way data is stored in JS is a much more complex process than the floating-point array load/store that other plugins like synths are employing. It is complicated further by a mechanism that allows us easy compatibility between versions, which is very important due to the frequent updates we release. I mention this to explain why load/store is so time-intensive.

Ralph,

I just thought of a novel way to solve this problem, no matter how complex the internal Jamstix data is. Unfortunately I need to go right now but I will post my solution sometime today...

A novel solution (I think) to complex problem...

Ralph,

So after what you said about the complexity (read: memory/CPU consuming operation) of using a brute-force way to implement an Undo/Redo feature, I thought about the problem and the following solution came to mind:

[b:0f946feba6]Problem:[/b:0f946feba6]
The user makes a change to a control, resulting in Jamstix invalidating all or part of the song so that it will be re-generated with the new setting. To support an Undo/Redo feature, Jamstix will need to take a snapshot of the state just prior to when the new setting is applied (and new data is generated). This includes all control settings, as well as all of the current song data. Because of Jamstix' complex data structures, as well as its complex serialize/deserialize implementation, this is a very time-consuming operation, and possibly also consumes enough memory so that having multiple snapshots at the same time would consume too much memory. Saving the snapshots to disk will only require more CPU cycles. Hence this solution is not possible.

[b:0f946feba6]Use case:[/b:0f946feba6]
The user goes to the Fill section, and presses the Compose button. Jamstix uses a sequence of random numbers from a random number generator to create a new fill sequence based on the current control settings, as well as a number of other settings, like the selected drummer, etc. Every time the user clicks on the Compose button, or changes a control value, the fill is re-generated from a new sequence of random numbers and current settings.

[b:0f946feba6]Solution:[/b:0f946feba6]
My solution works by saving the old and new state of any control that a user changes (including the basic controls, as well as selecting a new drummer, manually edited events, etc). Also, in addition to saving individual control changes as an Undo/Redo point, it also saves a random number generator [b:0f946feba6]seed number[/b:0f946feba6]. This number can be generated by the random number generator itself, since it doesn't matter what the value is, as long as it can be recalled later.

So the flow is:
1. At startup, Jamstix initializes the random number generator with a randomly generated seed number, and stores the seed number as the current seed.
2. Jamstix composes the fill using a sequence of random numbers.
3. The user clicks Compose.
4. Jamstix saves the click event, including the current seed number into the Undo stack.
5. A new seed number is generated from the random number generator, and saved as the current seed number.
6. Jamstix composes the fill using a sequence of random numbers.
7. The user clicks Undo.
8. Jamstix pops the undo info from the stack (and any saved changes to individual controls), and initializes the random number generator with the popped seed number.
9. Jamstix composes the fill using a sequence of random numbers.

The important thing to note here is that the fill that was generated in step 9 will be [b:0f946feba6]identical[/b:0f946feba6] to the fill that was generated in step 2, even though the only thing that was saved was a single number (the seed number). Voila - A reliable yet lightweight Undo/Redo!

Of course the same concept will apply to any other part of Jamstix as well, not just fills. In the case where the user modifies a control, the only additional undo data that needs to be saved is the control ID, old value and new value.

This solution will work because random number generators are really "pseudo random". You can retrieve an unlimited number of "random" numbers, except that by supplying the same seed number at the start of the series, the series of "random" numbers will be [b:0f946feba6]100% repeatable[/b:0f946feba6].

The amount of CPU cycles such a solution requires will not be much more than that required when the user manually modifies a control. Memory requirements will be extremely low, and you can probably save an entire day's worth of Undo/Redo in one session without going to disk.

I'm just saying...

[b:0f946feba6]Edit:[/b:0f946feba6] That was basically just a very long-winded way to say that instead of saving the data itself, save the way that the data was generated. Which in this case boils down to a single number - the random number generator's seed number. That's a hellava compression ratio!

Thanks for you input on this!

We cannot use PRNGs because once you reload a seed via UNDO, all subsequent numbers are identical, reducing the 'permutation bandwidth' of the A.I. and even leading to the exact replication of previous structures if the user uses UNDO in certain sequences (i.e. compose,undo,compose yielding identical fills). There are ways of getting around this by there is no payoff versus full fill load/store since memory usage is not really an issue.

The Undo/Redo issue centers less on memory usage and more on cause & effect. Here is just one example: let's say the user clears a part, which destroys all recorded notes in its bars (which could be hundreds). There is no way to undo this unless all that bar data was stored at the time of the user action.

May I also suggest to take this exchange to email instead of this thread? We are likely boring people to death

Ralph [RZ] wrote:Thanks for you input on this!

We cannot use PRNGs because once you reload a seed via UNDO, all subsequent numbers are identical, reducing the 'permutation bandwidth' of the A.I. and even leading to the exact replication of previous structures if the user uses UNDO in certain sequences (i.e. compose,undo,compose yielding identical fills). There are ways of getting around this by there is no payoff versus full fill load/store since memory usage is not really an issue.

The Undo/Redo issue centers less on memory usage and more on cause & effect. Here is just one example: let's say the user clears a part, which destroys all recorded notes in its bars (which could be hundreds). There is no way to undo this unless all that bar data was stored at the time of the user action.

May I also suggest to take this exchange to email instead of this thread? We are likely boring people to death

Ralph,

I am disagreeing with your assertion about the loss of randomness (I think you misunderstood my explanation), as well as your point that the data cannot be recreated as in your last example. But I will respond in an email. I have no idea which email address to use, though...

r.zeuner at rayzoon.com

I'm not bored.

And I don't see the problem with saving before you know you're going to experiment, but that's just me.

Lyin Dan wrote:I'm not bored.

And I don't see the problem with saving before you know you're going to experiment, but that's just me.

I guess you are right, but there have been enough times where I forgot to do a save, changed something and wished I could go back (like a fill, for instance). An Undo/Redo would have been great at those times.

Well I think Ralph and I seemed to agree that from a technical point the solution might work, but from a practical point, it will require a lot of changes because each control will need to be updated to do the right thing.

Also, I am not 100% sure Ralph agrees with me on the repeatable random data generator (although I am 100% sure it will work), but since this is probably not going to be implemented, it is kinda academic at this point.

This is my first post so probably doing something wrong but....

Ralph, is there any chance of having the facility to insert VST effects in the JS3 mixer? I've looked through this thread and can't find any mention of it anywhere.

burble_healing wrote:Ralph, is there any chance of having the facility to insert VST effects in the JS3 mixer? I've looked through this thread and can't find any mention of it anywhere.

Technically feasible but it's not the path we are pursuing. Most customers use the host's FX bin for that.