You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if a user changes the number of x-slots in a sign to a smaller number, this causes problems in the timing units.
E.g. for BOSS (v. 3) in the 2023_06_28_BLOW_v1_BOTH_v1_MR_KCH_YG.slpaa corpus:
The original coding has four x-slots:
If we want to make this two x-slots and just manually switch it to two, the modules assigned to x3 and x4 are stranded as 'ghosts' and make any other edits difficult because they're still coded (partial screenshot because it doesn't all fit on my screen):
Not entirely sure what the best way to handle this is, because it would be a drag to re-set all the timings, and we don't even have a way to host a module that has no timing associations. Is it possible to remove any timing associations that are linked with modules that are greater than the number of x-slots (so e.g. if we go from four to two x-slots, any associations to x3 or higher are removed) -- so, we'd have to reach 'inside' a module and remove some of its timings? And I don't know what happens if all of the module's timings are in these higher-number x-slots....
Maybe it's easier if we simply force the user to manually adjust the timings to match what they want before we let them downgrade the x-slots? So e.g. if they try to go from 4 to 2, we give them an error if there's anything linked higher than x2, and require that they 'pretend' there are two x-slots and do the associations before actually downgrading?
The text was updated successfully, but these errors were encountered:
I think no matter what, if the user tries to reduce the number of x-slots for a sign, they should be warned. And then either we have a standard way that we deal with the issue, or we let them choose. Just brainstorming options...
All modules get reset to "whole sign"
All modules that are problematic get reset to "whole sign" but those that fit the new timing are left as is
Any links higher than the new number of x-slots are flagged (as you suggested above), and we make the user fix everything before we let them change the x-slot structure.
Any links higher than the new number of x-slots are removed (as you suggested above), and if that means ALL of the links are removed, then it's reset to "whole sign"
All timing gets reduced by the same fraction as the x-slot structure (eg, if you are reducing from 4 x-slots to 2, then all link timing as cut in half). This is problematic if the newly-reduced fractions aren't part of our available repertoire (eg, a point at 1/3 of x1 can't be reduced to 1/6 of x1).
Currently, if a user changes the number of x-slots in a sign to a smaller number, this causes problems in the timing units.
E.g. for BOSS (v. 3) in the 2023_06_28_BLOW_v1_BOTH_v1_MR_KCH_YG.slpaa corpus:
The original coding has four x-slots:
If we want to make this two x-slots and just manually switch it to two, the modules assigned to x3 and x4 are stranded as 'ghosts' and make any other edits difficult because they're still coded (partial screenshot because it doesn't all fit on my screen):
Not entirely sure what the best way to handle this is, because it would be a drag to re-set all the timings, and we don't even have a way to host a module that has no timing associations. Is it possible to remove any timing associations that are linked with modules that are greater than the number of x-slots (so e.g. if we go from four to two x-slots, any associations to x3 or higher are removed) -- so, we'd have to reach 'inside' a module and remove some of its timings? And I don't know what happens if all of the module's timings are in these higher-number x-slots....
Maybe it's easier if we simply force the user to manually adjust the timings to match what they want before we let them downgrade the x-slots? So e.g. if they try to go from 4 to 2, we give them an error if there's anything linked higher than x2, and require that they 'pretend' there are two x-slots and do the associations before actually downgrading?
The text was updated successfully, but these errors were encountered: