Rayzoon Technologies LLC

[lucky]

Hi there,

not been active here for a long time due to other priorities. But picked up on Jamstix again and tried the betas of Jamstix 3. The latest beta 11 causes Cubase SL2 (I know, it’s sad) to hang while loading Cubase. The previous betas didn't have this problem, but beta 11 stalls loading of the program.

On a side note: I'm curious about the new styles and/or drummers. Any change there will be more Jazz, Funk & Jazz-rock stuff in there?

Call me lazy, but I sure would love to see more 'lock & load' songs for some straight (live loop) jamming. There are already so many styles, drummers and options, that as a bass player I feel a bit lost. Which style to which drummer and with what variations?! This might sound spoiled, as you give us so much, but I just want to pick up my bass, start jamstix and jam.

Maybe like a jam pack, consisting of a couple of songs of a particular style, e.g. funk, jazz, etc. Each song contains 3 parts that fit nicely together, either as a verse, chorus & bridge structure, or as 3 different flavors of a beat, e.g. basic, heavy & quite. Maybe as an add-on pack. Just a thought.

R, Lucky

[R Green]

Apologies for time waste, I used the link to the manual earlier in this thread so I could have a look at it during lunch. Suggest that link is disabled? Did not know it came with the installer - will use at home only from now on.

[BitFlipper]

Please...

Can we get a true Undo/Redo function? The more new ways added to modify an existing composition in unexpected ways, the more a true Undo/Redo function is needed. The restore point functionality just doesn't cut it for this type of application.

Just two simple buttons: Undo | Redo. This will encourage much more experimentation without the fear of losing a good composition.

Please...

BTW, as someone that has been doing software development for almost 20 years, I have implemented quite a few Undo/Redo features myself. You just need to be able to capture the current state fully (including all control settings) into a memory snapshot (or save the last 10 to 100 [user selectable?] or so snapshots to disk if it is just too big), and store it using a stack algorithm. The theory is pretty simple, and in practice it is usually trivial to implement compared to most other features. So why exactly not do it for Jamstix then...?

I think this is one case where the developers miss the importance of a feature like this because running test cases, etc, you don't need an Undo/Redo feature. In real life use, you do.
_________________
Intel DX48BT2, Core 2 Quad Q9450 @ 2.66GHz, 8GB DDR3, Edirol FA-66, Studio One 2, Sonar X3e x64, JS 3.6.0, Windows 8.1 Pro x64

[Ralph [RZ]]

Undo/Redo is just not that easy. Saving the entire data state every time a dial is turned in the brain etc. would consume too much time, especially since GUI and audio thread (which both access the data) must be synchronized on multi-core systems, so you'd likely have audio dropouts as soon as the arrangement reaches a certain # of composed bars and you are using anything but high latencies.

The way I use JS, I always save in the host or save a restore point in JS before doing any 'experimentation'. Another option is the auto-save feature of JS.

Let me stress that I would love full Undo/Redo just as you do. I'm just pointing out the difficulties with its implementation in this specific environment.
_________________
Ralph Zeuner
Rayzoon Technologies LLC
http://www.rayzoon.com

[BitFlipper]

[Ralph [RZ]]

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 Zeuner
Rayzoon Technologies LLC
http://www.rayzoon.com

[BitFlipper]

[BitFlipper]

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:

Problem:
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.

Use case:
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.

Solution:
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 seed number. 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 identical 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 100% repeatable.

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...

Edit: 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!
_________________
Intel DX48BT2, Core 2 Quad Q9450 @ 2.66GHz, 8GB DDR3, Edirol FA-66, Studio One 2, Sonar X3e x64, JS 3.6.0, Windows 8.1 Pro x64

[Ralph [RZ]]

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 Zeuner
Rayzoon Technologies LLC
http://www.rayzoon.com

[BitFlipper]

[Ralph [RZ]]

r.zeuner at rayzoon.com
_________________
Ralph Zeuner
Rayzoon Technologies LLC
http://www.rayzoon.com

[Lyin Dan]

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.

[BitFlipper]

[burble_healing]

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.

[Ralph [RZ]]