Printable View
FABC
FDEF
If someone would make 2 different Synchromuse sessions (they need only be a segment or two) using the header names above, and then see if the DAS distinguishes between them when playing the audio, it will help me a lot.
I've done the same, and the Procyon would always initiate the session that was loaded first.
Thanks.
I have tried this and I see what you mean. For me, it triggered session 30. I don't think this was the last session I played but maybe. Could you see if yours triggered session 30? When you switch to SES mode after running the trigger the currently selected session should be the one that was triggered. Then I can investigate more.
My suspicion is that these header names translate to Hexadecimal values and that might be creating a problem...
When I was testing this, all pre-loaded sessions were wiped, so there was only Session0. Switching to SES, the last session triggered was played. In all cases the triggered session was the first one loaded into the Session List, regardless of the header.Quote:
Originally Posted by neuroasis
Ha - that's thinking outside the box. If it's the case then there is something terribly wrong with the DAS triggering algorithm.Quote:
Originally Posted by neuroasis
I guess it could be easily tested with a simple change from Hdigit to letter - except for the problem of false postives. For example if changing one of the digits to X or Y fails to work the problem could also be the length of the header. I do not know if the keyboard layout could be a issue as I'm using danish - but then the problem could be Audacity which is unlikely. But it should be anyway a simple comparison so the actual character used shouldn't matter - maybe if there are excluded characters that DAS would reject, and Audacity produces one:icon_rolleyes:.
It is hard to see what could be wrong here, given that no one else appears to have had problems playing different Synchromuse sessions.
After testing bunches of combinations, it seems that every 4 (and maybe 5) byte header that begins with the letter F, triggers session 30 in the factory sessions with no audio. That is what is happening on my end. 6 byte headers that begin with F work and 8 byte. These are the RAW files played directly from Audacity with no output conversion...
There are so many possibilities to test that confining it with tests for the letter F would be a start. BTW, I have seen a similar problem with SM triggers using numbers as the beginning character. Never have gotten back around to trying to nail it down but now that there is another report I will revisit it.
Can you verify this is the case?
So far combinations of lowercase f work fine... I also find that 4 byte combinations of uppercase C trigger session 6 of the factory sessions... really weird.
Weird, indeed--and thanks to you both for your dialog on this underused and underreported Procyon feature. I'll contact the project engineer and ask him to look into this. My intuition parallels Scotts: that the issue has to do with hex translation or rollover (etc.) issue.
Yes, it is weird. But thanks, now I can continue making the sessions using only lower case, and 6+ digits just to be safe. If this could be documented as a workaraound it may help others avoid the problem, at least until it is fixed.
Here is what I am finding...
The problem is that files with headers that start with the same letter will only trigger the first instance of that letter.
Capital letters are treated differently than lower case.
So fabc and FABC are separate headers.
Both will work together but
if I later add FBAC then the earlier entry FABC will be the one that triggers.
fabc and fuzz will play first entry.
Numbers are a little different: 1Hz and 11Hz (names) only trigger first entry 1Hz.
Same way, 11111111 and 11111112 trigger first entry but
12222222 triggers different entry.
But, 11112222 triggers first entry 11111111...
11122222 plays fine. Boundary is the 4th byte?
I see no difference between DABC and DABCDABC, plays first entry DABC.
No difference between SlrNbhd and SOLAR, plays first entry....
Summary, separate headers cannot start with the same letter or number... Numbers may be different if beyond 4th byte (needs more tests)
So for creating SynchroMuse be sure that each file header starts with a different letter of the alphabet. 26 uppercase possibilities, 26 lower case possibilities. Starting with unique numbers is allowed too so 0-9 for sure but there may be additional values allowable which needs further testing.
A zip archive of my test files is attached if anyone wants to confirm my findings. Project engineer has been notified and hopefully a fix will be forthcoming.
This worked for me, at least have got 14 distinct headers working, so thanks for sorting it out.Quote:
Originally Posted by neuroasis
I wouldn't hold your breath.Quote:
Originally Posted by neuroasis
O, ye of little faith! :) Here is an updated editor and Procyon OS. From running all my tests, the problem seems to have been addressed successfully. Please check on your end and verify so we can release it to the community.
You will need to run the new editor and update the Procyon OS... backup your stuff prior to testing.
:headbang:
Damn, I jumped into that.Quote:
Originally Posted by neuroasis
That's great. I hope it does drag+drop.Quote:
Originally Posted by neuroasis
I will, though if it works on yours.... :cheers:Quote:
Originally Posted by neuroasis
What would you like to drag and drop? Sessions to upload?
Yes, or have the PRw files associated with the Editor so it only takes a double click.Quote:
Originally Posted by neuroasis
The trigger problem seems to have been fixed, so that's great.
The Editor can be a bit weird, like sometimes it takes a long time to start up. Or a session file can be opened, but the previous values remain.
Do you know what the Procyon does if 2 headers have identical names?
I think it would just pick one of the sessions (probably the first if the headers are the same) People report different conditions in which odd things happen with the editor but I actually have very little issues of my own and I use it all the time. If you find a consistent reproducible issue, please let me know.
Scott