Discouraged that song bundles for NS3 seem to be broken

[ericL]

I haven't moved big bundles of songs around lately, though I learned a few years ago that NS3 song bundles create errors in batches larger than 5 songs. I have a really HUGE gig tomorrow and it's essential that my backup NS3 has exactly the same data as my gig NS3.

I spent a few hours programming and cleaning things up tonight, with the last step to upload the song bundles for 20 songs that feed my gig tomorrow. I decided to try the full 20 songs first. It uploaded to my laptop, but errors when trying to download to the backup NS3.

Then I took some smaller batches of 5 programs each and none of these would work either. I got errors all along the way. It is EXTREMELY frustrating and I am just giving up after wasting a ton of time on it.

I guess not many people use this and Nord isn't debugging it in subsequent versions of NSM. I had a prior version of NSM on my laptop where I know it worked previously but no good now. The latest version doesn't work. So I guess I am done trying to save bundles of NS3 songs. The only thing I was able to get working was a *SINGLE* song. That is not scalable and I do not feel like I want to upload each song individually. Sigh.

Am I the only one trying to use this feature? Any other ideas or suggestions? Thanks.

[ericL]

Upon some further inspection of the few song bundles that were accepted in the target NS3, I think I am onto something. I might have an edge case that is messing with the NS3 song naming structure and thus blowing it all up, perhaps this wasn't tested or they don't consider upper case vs. lower case in the naming convention...or I found a bug or whatever.

I've shared before that I play in multiple bands and so I have a naming convention for programs and sounds in my NS3. My band The Usual Suspects has songs that are called "US Separate Ways" and US is the way I keep those things separate. My band Flat Elvis has songs like "FE Lets Go" and my band Fighting Gravity has "FG Song ABC" etc. across other bands too.

Tonight I tried something tricky as I had refactored nearly all of my Fighting Gravity aka "FG" songs. I have 20 updated songs/programs bundled where I want to upload them to my laptop and then download to my backup NS3. I was trying to create a unique naming convention so that I could bring these over and not have them conflicting with other songs that exist. So I took "FG Song ABC" and named it "fg Song ABC" then bundled and uploaded it with other songs...and then it bombed when I tried to download to the other NS3. The target NS3 already had the "FG" version named but not the "fg" version, even if the data in each was different.

The only couple of songs I found that worked before the errors kicked in were brand new songs that didn't previously exist in each instrument such as "fg Song XYZ" that wasn't in the target NS3 as "FG Song XYZ" so I think maybe I'm pushing this song bundle and naming convention a point that hasn't been tested. LOL. Sigh, I may be alone in my struggles.

[FZiegler]

Somehow, this could indeed be an issue - even if I don't exactly know how. In bytes form, "FG" and "fg" need to be different. But I probably wouldn't have risked that sort of differentiation. If ever this is a problem, you of course should let know Clavia Nord.

As renting a Nord Stage, Electro or Piano and uploading your own bundles should be a safe thing to work, Nord should be quite interested in your struggle.

Until now, I didn't have problems with bundles, but I really rarely loaded some. And I haven't updated NSM for a long time as it worked for me.

[anotherscott]

Systems these days usually don't distinguish between upper and lower case. It's a way to make them more "human friendly," similar to how MIDI's 0-127 can be turned into 1-128 for human convenience. It's also why sorted lists can show things in human-convenient order rather than upper case A-to-Z followed by lower case a-z, which is "alphabetic order" internally (ASCII). It's also why if you have a file named ABC, a computer may balk if you try to create a file abc in the same place, telling you there's already a file with that name (even though, from the computer's perspective, there really isn't). And why people who were online in the early days had to be careful about caps vs. lower case in their URLs or email addresses, but don't anymore.

[cgrafx]

Systems these days usually don't distinguish between upper and lower case. It's a way to make them more "human friendly," similar to how MIDI's 0-127 can be turned into 1-128 for human convenience. Also why sorted lists usually show things in human-convenient order rather than upper case A-to-Z followed by lower case a-z, which is "alphabetic order" internally (ASCII). It's also why if you have a file named ABC, a computer will balk if you try to create a file abc in the same place, telling you there's already a file with that name (even though, from the computer's perspective, there really isn't). And why people who were online in the early days had to be careful about caps vs. lower case in their URLs or email addresses, but don't anymore.

the upper/lower case issue, isn’t done for human readable convenience, it is 100% dependent on if the operating file system is case sensitive or not.

windows, not case sensitive. mac case sensitive if set up that way. linux, unix mostly case sensitive.

based on your description/problem Nord picked, or setup their file system as case insensitive, and don’t distinguish between upper and lower case letters. it’s, not right or wrong, it is just the way it is.

[anotherscott]

the upper/lower case issue, isn’t done for human readable convenience, it is 100% dependent on if the operating file system is case sensitive or not.

I"m not saying all systems are set up that way, but IF a system is set up to be not case sensitive (whether at the operating file system level or elsewhere), that decision was made for human convenience. Because internally, there is *always* a difference between the ASCII for upper case vs. lower case. So if anywhere along the line, additional coding was done to "hide" that difference and to instead treat those two ASCII values as functionally equivalent, it would have been done because it's generally more convenient for humans when things behave that way.

[anotherscott]

You are right, it is documented in the Nord Stage 3 - Update History page:

v1.26 (2017-11-16)
Names are now compared non-case sensitive when checking if a file name exists during Store operations.

[anotherscott]

You are right, it is documented in the Nord Stage 3 - Update History page:

v1.26 (2017-11-16)
Names are now compared non-case sensitive when checking if a file name exists during Store operations.

The OP has run into a genuine case of, "it's a feature, not a bug."

[ericL]

You are right, it is documented in the Nord Stage 3 - Update History page:

v1.26 (2017-11-16)
Names are now compared non-case sensitive when checking if a file name exists during Store operations.

The OP has run into a genuine case of, "it's a feature, not a bug."

Thank you for the insights and for sharing that what I did was exploiting a planned "feature" - although, if that was working how I'd want it to work, I would prefer if the NSM did something like it does when it finds the same named programs during a bundle update. It throws an error prompt such as "The program Eric Piano Jam already exists, do you want to keep the original or update with the new version?" I've also seen where if I save a program or song with the same exact name that the NS3 will append a number on it like Eric Piano Jam 1 or similar.

I was simply getting some weird system error with my "fg" vs. "FG" named songs in a bundle. Oh well.

I suppose my best solution will be to add a different letter or numbering to the "fg" songs that I want to show as new and distinct. One day I'll figure it out.

[FZiegler]

I still believe this should be reported. Exactly what you suggested, ericL, would be nice.