#176 ANSI Music Not Working in Latest Versions

[Alex Corris]

Hi, I know ANSI music is a huge pain and not standard, but up until a couple versions ago I could write this to the terminal: #27 + [N + T120O4E16 and get sounds

Now it just displays on the screen no matter what ANSI Music setting I have on in Sync. I only noticed this starting in 1.3, but I'm not sure when it started really. I just tested with 1.4b with same result. Thanks for all the hard work, and if this is just not the right way to do it I can easily change my code to a preferred method which I thought this was (as preferred as can be with ANSI music anyway).

[Alex Corris]

Just a quick note too, it appears that Sync recognizes it's music based on the addition of the music symbol at the end (shows for all settings under Alt-M) - https://imgur.com/a/eXdukCA

[Stephen James Hurd]

ANSI output mode has never supported ANSI music that I'm aware of, it just passes it through to the final terminal. Can you test in GDI or X11 mode (depending on your OS) and see if it works there?

I'm curious what you're using ANSI output mode for.

[Stephen James Hurd]

I just confirmed that running SyncTERM in X11 mode with a shell, then running SyncTERM in ANSI mode inside the first one and playing ANSI music works correctly.

[Anonymous]

Wow! No kidding. I would have never guessed it was the OS. So I went back to a really old version of SyncTERM and it still did not work, completely verifying what you said. Then I served the door up on a windows machine and it worked like it always has. So it seems to work on GDI, and it used to work on X11 until a recent update of Ubuntu. I can't say for sure when, but I noticed it stopped working a couple months ago maybe? I hadn't started to try and figure out why until today when I assumed it must have coincided with my update of SyncTERM during your testing phase.

I'm using ANSI output mode for a door game that uses some lesser used things like ANSI Music.

[Stephen James Hurd]

Note that the outer terminal needs to support BANSI style ANSI music for the pass-through to work. If it doesn't you'll see it being printed like that.

[Stephen James Hurd]

If it's SyncTERM as the outer terminal on X11, make sure that the connection settings you're using has the "ANSI Music" setting set to either "BANSI Style" or "All ANSI Music enabled".

[Alex Corris]

I don’t have an outer terminal. Using SyncTERM when the door is served through windows works, SyncTERM same settings when the door is served via Linux no longer works, but was working recently.

[Stephen James Hurd]

Oh, the ticket shows "Output Type" as "ANSI" which means running SyncTERM with -iA... in that mode, instead of opening a window, it runs in a terminal. Can you verify that the dialing entry on the Ubuntu system has the correct "ANSI Music" setting?

[Alex Corris]

Oh gosh! Sorry! Now the replies make more sense. As far as the ANSI Music setting I've tried all three. I believe BANSI was the setting that worked in the past, but not sure. The only changes I can think of on that server were regular Ubuntu updates.

[Stephen James Hurd]

Can you give me the address of your BBS and a description of which door to go to and how to get it to play ANSI music so I can test it?

[Anonymous]

No problem! I set up a brand new Synchronet Install, Installed the Door, and the issue exists. Same code running on Windows works.

Working Example (Windows): Telnet to bbswordle.com -> [P] Pig from main menu
Non Working Example (Linux): Telnet to 54.202.159.12 -> Xternal -> Games -> Pig

When you roll the die on the top one, you'll hear sounds (or press M to turn Ansi Music on). The Linux one you'll see the text displayed in the upper left.

Thanks!

[Alex Corris]

I keep assuming I'm still logged in, but this is what I just sent basically in the anonymous post.

I set up a new Synchronet server, and the ansi music does not play from it (Pig in the doors menu): telnet to - 54.202.159.12

Windows install, same code, works: telnet to - bbswordle.com [P] Pig

Music should play when you roll dice, you might have to hit M to turn music off and on. Thanks!

[Stephen James Hurd]

Ok, so a wireshark capture shows that you are not sending the CSI (ESC[) properly from the Linux system. Instead of 0x1b 0x5b, you're sending 0x1b 0x0d (\e\r), so it's not seen as an ANSI sequence.

This looks like a bug in the Linux code for Pig. :D

[Stephen James Hurd]

Or using the notation in the report, instead of #27 + [N, you're sending #27 + #13 + N

[Alex Corris]

Okay well, I guess at very least we can say 100% it's not SyncTERM and close the ticket. Thanks for the help on this! I'm still not sure where I should go from here though and I also understand if this is where the support would end because it's not specifically a SyncTERM issue.

Here's what I see on my end -

1. The complied binary was working untouched until a few months ago on Syncrhonet/Linux. Only running Linux updates - No Syncronet updates, no recompile.
2. The code is exactly the same between Windows and Linux, it's a cross compile. Although the door library might be passing something different on Linux compile, I don't see any switches that would indicate that. It also stumps me because it was working as of a couple months ago with no changes to a compiled binary.
3. I just installed Mystic on Linux and SyncTERM plays the music, but still also displays the text.
4. Not much to debug, it's one write to the screen, but verified it's [N I'm sending to the write.

I created a door called music door with compiles for Win32 and Linux64 that is bare bones and just does the writes. It's live on telnet bbswordle.com (win) where it works fine, and also on Mystic at 54.202.159.12 (Linux) where it plays the music now on SyncTERM, but also displays it messing up the screen.

I uploaded the test door here just in case: http://bbswordle.com/releases/musicdoor.zip

[Stephen James Hurd]

I think the first thing to figure out is exactly where the data is going bad... maybe have the door log what it's sending and see if that's right, then work out the chain to see where it first goes bad.

I'm not sure now if you're running Mystic or Synchronet on 54.202.159.12... I know Synchronet is unlikely to modify the data stream, but I don't know much about Mystic.

[Stephen James Hurd]

Looking at the capture from the Mystic, it's sending the music sequence multiple times, the first four times correctly, then once #27 + #14 + #13 + #10 T120... then once as #23 + #14 + T120...

With the \r\n inserted, I suspect it may have to do with either the door library or BBS system auto wrapping lines or something. My first suspicion would be the door library.

[Stephen James Hurd]

Yeah, looking at the capture, I receive this (C format):

"\033[N"                       <-- not terminated with \016 at all.
"\033[m"
"\033[1B"
"T120O4D16T120O4D16\016\016"   <-- will be printed
"\033[NT120O4D16T120O4D16\016" <-- will play
"\016"                         <-- displays notes
"\033[NT120O4E16T120O4E16\016" <-- will play
"\016"                         <-- displays notes
"\033[NT120O4E16T120O4E16\016" <-- will play
"\016"                         <-- displays notes
"\033[NT120O4D16T120O4D16\016" <-- will play
"\016"                         <-- displays notes
"\033[NT120O4E16T120O4E16\016" <-- will play
"\033[N\016"                   <-- Valid, but nothing to play
"T120O4D16T120O4D16\016"       <-- will be printed
"\033[N\016"                   <-- Valid, but nothing to play
"T120O4E16T120O4E16\016"       <-- will be printed
"\033[N\016\r\n"               <-- Valid, but nothing to play
"T120O4D16T120O4D16\016"       <-- will be printed
"\033[N\016"                   <-- Valid, but nothing to play
"T120O4D16T120O4D16\016\016"   <-- will be printed, ends with two notes
"Your music has been played, press any key.\r"
"\033[1B"
"Your music has been played, press any key.\r\n"

So it's messed up a lot around the [N bits. There's even a #27 [N with no music string (or ending string) at the beginning.

It looks like they all have two #14 and some have them both at the end, but some have them after the "N". This really does look like a door library issue.

[Alex Corris]

That was actually on my end. I noticed and fixed that when I wrote the logfile out both versions attached, one Linux, one Windows. When I open in Sublime they look exact, when I open in notepad the escape character looks slightly different.

• GameSvr Windows Works
• Mystic Linux - Plays and Displays
• Synchronet - Just displays in standard mode, plays in socket mode but also no longer takes keyboard input

The .zip file has also been updated on the server and includes logging.

[Stephen James Hurd]

Yeah, there's some very weird things happening here... it's actually erasing the screen by writing spaces to it, and now every music string is written a second time, but without the #27[N in front of it.

This looks to me like something (likely the doorkit) is actually updating an internal copy of the screen and sending updates periodically... and that thing doesn't know about ANSI music. #27[N is actually a valid ANSI by itself ("erase in field") and what's being sent that displays it is what that would be shown on a screen that did support erase in field and did not support ANSI.

I'm 90% certain there's an ANSI parser in there that's updating an internal view of the screen and then sending updates to the remote.

[Anonymous]

(Rick, doorkit author, too lazy to register)

The doorkit as it exists in the master branch does write the output through an ansi parser, which doesn't support ESC[N, so is definitely partially to blame. There's a branch that bypasses the parser in STDIO mode that I should have merged into master long ago that should help.

But it doesn't look like it's fully to blame. I modified Alex's test door to eliminate the doorkit and just call Crt.Write directly, and a problem still occurs where some of the notes are displayed to screen instead of played as sounds.

I found that if I call Crt.WriteLn instead of Crt.Write then things work perfectly audio wise, but of course that results in the cursor moving which is undesirable.

I also found that if use a loop to Crt.Write() each character in the ansi sequence individually rather than as one string, then every note is displayed to screen instead of played as a sound.

Not sure if any of that helps?

[Stephen James Hurd]

I'm happy to look at captures (tcpdump or wireshark) to see what's going on. There's certainly still a possibility of a bug in SyncTERM or Synchronet.

The thing that springs to mind is that Synchronet does allocate a pty for stdio doors, so if the Crt is doing interesting things with termios (basically, anything but setting it raw), that will mangle stuff in wild and wacky ways.

I think figuring out why the socket mode support isn't working may be more profitable because there's a lot less weird historical state things that can bit you.

[Rick Parrish]

Forgot to mention in the previous message that running the door under Mystic exhibits the same behaviour (3 notes display instead of play), so probably not a bug in Synchronet (unless Mystic followed Synchronet's lead on how to run externals and implemented the same bug...)

And also forgot to mention that socket mode works perfect on that un-merged branch, but that only helps Synchronet because AFAIK Mystic doesn't support socket doors (but maybe it does and I'm messing up the setup).

I'm going to try a few other things and if all else fails will install wireshark.