as well, when I reopen, things are missing;
eg I had made a track 1 copy with 8 banks setup for devices with 8 encoders each.
When I open up, the copies now only have 1 parameter bank, not 8.
Not great losing work...hopefully version from yesterday is available in gdrive
I'm not sure why/how this could have happened, as I know you have been working directly in the json:
Its possible the parameters are still in the json but they have just stopped displaying for some reason.
Maybe the parent Device's ID has somehow changed and they have become orphaned params. Its strange that parameter 8 is still there...
What weird is that in this case, this script has only been modified in css. The control surface gets updated but the ids are hardwired?
Aside from the dropped entries, its definitely not storing the order...its is as per the previous bug.
So it was out of order after you manually edited the json file?
We can't provide support for issues encountered after making changes manually as it could easily have been caused by your own edits.
No, as Im doing edits, when duplicating, sometimes it put copies above the current selected or sometimes below. After I have done reordering and eg come back the next day and reopen CSS, the order is not saved.
I totally understand re external editing but I havent edited the actual script externally, only the control surface gets updated externally. The previous bug also happened with no external edits at all.
Ok, some more info: its getting quite urgent to fix;
I have attached some pics.
1. Open the file
2. Reorder the items
3. Close and reopen...all is well...sometimes
BUT
1. Open the file
2. Reorder the items
3. Work down the lpage where the top items are not visible
4. Edit and reorder
WHEN I go to drag items up to the top of window/list...the orig items have gone back to the disorder.
Small projects seem to be ok: Its when there are long lists
Even when I reopen larger reactions etc, they go back to original disorder (pic 4 was grouped by G1 - G4 but you can see its now whacky)
Very hard to work with this bug...I am not able to finish the current project because of order dependencies
Thanks for including more detail, would it be possible to record a quick video of it happening for us to take a look at? it would help massively in tracking this bug down.
Or send over a script in which this happens and we can try it based on your notes above.
It's driving me nuts! I've barely scratched the surface of an 11-mode script that's going to involve a lot of back and forth comparison. Each time I open a mode, I have to organise the mode selectors and initial controls; only for them to jumble up again after I've collapsed the mode, gone to another, and returned to the original; or on relaunching CSS.
It's not just the content of each mode, but the modes themselves. They should be organised in the script "Mode 1a, Mode 1b... Mode 5a, Mode 5b, Shift Mode". But on opening, I get 1a (thankfully that stays at the top), 2a, 3a, 2b, 4a.
The modes also appear in the Mode Selector settings 'Select Mode' combi box in a jumbled order.
Is a 'Sort alphanumeric' option possible in an upcoming release, please?
Here's what I'm working on... (nk2_00_00_22-4abletonmodes1usermode.json) which, sod's law is now behaving itself! However... The action that earlier seemed to trigger the persistent reshuffling behaviour was...
- Duplicate a Mode Selector
- Whilst still in the same Mode group, open the new Mode Selector's settings and rename it
- With the cursor still in the Mapping Name field, delete the new Mode Selector by clicking its trash icon
And sure enough, I just recreate the bug! Nice! :D
Following those steps didn't shuffle my modes, but did shuffle the content within them. Please compare screenshots provided. I also provide a second version of the script (nk2_00_00_22z-reorderedafterduplicaterenamedeletesteps.json). This is an export of the one that just balls'd-up, which I have reorganised into desired structure. Having now quit and reopen CSS, it IS keeping that structure, so I believe there's another step that caused the jumbling on a reopen.
Update: I just recreated this bug with similar steps to those given above. This time I was adding Track objects. I added two too many Solo objects. Deleting them caused my script to jumble up. This was only the objects with each mode, not the modes themselves.
I organised the objects again. Installed, then exported the script. Quit CSS and rebooted my machine.
Upon launching CSS, all modes are jumbled. All objects within the modes are organised. *sigh*
Yay...at least someone else is getting this. It makes organising larger projects, a real burden
Seems to be on larger projects...my controller script alone has over 300 entries...so yeah...makes it really hard
Comments
as well, when I reopen, things are missing;
eg I had made a track 1 copy with 8 banks setup for devices with 8 encoders each.
When I open up, the copies now only have 1 parameter bank, not 8.
Not great losing work...hopefully version from yesterday is available in gdrive
Cheers
Please see pics for more accurate illustration
?
I'm not sure why/how this could have happened, as I know you have been working directly in the json:
Its possible the parameters are still in the json but they have just stopped displaying for some reason.
Maybe the parent Device's ID has somehow changed and they have become orphaned params. Its strange that parameter 8 is still there...
What weird is that in this case, this script has only been modified in css. The control surface gets updated but the ids are hardwired?
Aside from the dropped entries, its definitely not storing the order...its is as per the previous bug.
So that we can try and replicate this issue, has the reordering only happened inside copies of tracks?
No, I cleaned up my file today and it was out of order again when I reopened
So it was out of order after you manually edited the json file?
We can't provide support for issues encountered after making changes manually as it could easily have been caused by your own edits.
No, as Im doing edits, when duplicating, sometimes it put copies above the current selected or sometimes below. After I have done reordering and eg come back the next day and reopen CSS, the order is not saved.
I totally understand re external editing but I havent edited the actual script externally, only the control surface gets updated externally. The previous bug also happened with no external edits at all.
Right I see, we will try and replicate this issue then.
any news?
We've not yet been able to replicate this.
If you have exact steps we can follow where this will happen, that would be a big help.
Ok, some more info: its getting quite urgent to fix;
I have attached some pics.
1. Open the file
2. Reorder the items
3. Close and reopen...all is well...sometimes
BUT
1. Open the file
2. Reorder the items
3. Work down the lpage where the top items are not visible
4. Edit and reorder
WHEN I go to drag items up to the top of window/list...the orig items have gone back to the disorder.
Small projects seem to be ok: Its when there are long lists
Even when I reopen larger reactions etc, they go back to original disorder (pic 4 was grouped by G1 - G4 but you can see its now whacky)
Very hard to work with this bug...I am not able to finish the current project because of order dependencies
Thanks for including more detail, would it be possible to record a quick video of it happening for us to take a look at? it would help massively in tracking this bug down.
Or send over a script in which this happens and we can try it based on your notes above.
Hi,
I'm experiencing this with v2.5.6
It's driving me nuts! I've barely scratched the surface of an 11-mode script that's going to involve a lot of back and forth comparison. Each time I open a mode, I have to organise the mode selectors and initial controls; only for them to jumble up again after I've collapsed the mode, gone to another, and returned to the original; or on relaunching CSS.
It's not just the content of each mode, but the modes themselves. They should be organised in the script "Mode 1a, Mode 1b... Mode 5a, Mode 5b, Shift Mode". But on opening, I get 1a (thankfully that stays at the top), 2a, 3a, 2b, 4a.
The modes also appear in the Mode Selector settings 'Select Mode' combi box in a jumbled order.
Is a 'Sort alphanumeric' option possible in an upcoming release, please?
Cheers
Jus
Here's what I'm working on... (nk2_00_00_22-4abletonmodes1usermode.json) which, sod's law is now behaving itself! However... The action that earlier seemed to trigger the persistent reshuffling behaviour was...
- Duplicate a Mode Selector
- Whilst still in the same Mode group, open the new Mode Selector's settings and rename it
- With the cursor still in the Mapping Name field, delete the new Mode Selector by clicking its trash icon
And sure enough, I just recreate the bug! Nice! :D
Following those steps didn't shuffle my modes, but did shuffle the content within them. Please compare screenshots provided. I also provide a second version of the script (nk2_00_00_22z-reorderedafterduplicaterenamedeletesteps.json). This is an export of the one that just balls'd-up, which I have reorganised into desired structure. Having now quit and reopen CSS, it IS keeping that structure, so I believe there's another step that caused the jumbling on a reopen.
JT
Update: I just recreated this bug with similar steps to those given above. This time I was adding Track objects. I added two too many Solo objects. Deleting them caused my script to jumble up. This was only the objects with each mode, not the modes themselves.
I organised the objects again. Installed, then exported the script. Quit CSS and rebooted my machine.
Upon launching CSS, all modes are jumbled. All objects within the modes are organised. *sigh*
This is a real PITA :(
Yay...at least someone else is getting this. It makes organising larger projects, a real burden
Seems to be on larger projects...my controller script alone has over 300 entries...so yeah...makes it really hard
Thanks for the details Jushia, we will try and replicate it here.
If we can then it will be a huge step towards fixing it :)
Good news, a fix for this has been included in the latest beta (2.6b1.6) available to download in the beta forum.