Can we talk about talkies (pun intended)!

That is because they are not the clearest. In aviation they’d “never fly” (no pun intended), morse-code would still be used if talkie_“something”_15 was the only alternative.

But it should be legible and can be as per my examples above.

What do you think of my “No S.D.” talkie recording above, I think it sounds really clear ? As far as I am concerned, it is the only only one that can’t have a “*.wav” on the SD-Card because without an SD-Card, it couldn’t be played from it.

All the other errors could potentially be “made to be played” from a "*.wav" on the SD-Card or a beeper code if the "*.wav" is missing independently of a voicepack present or not. And as a backup (for those who wish), a “somewhat ok” talkie could be used/or not.

Is that actually how they sound on the saber/encoded into talkie format?

All the above posted sounds were recorded from my saber to my iphone, sent to my pc, had the before and after “silence” cleaned with Audacity, converted to "*.wav" and posted here. So I’d say yes, that’s how they sound. I can’t hear a difference between direct “from saber”, “from iphone” playback (other than “silence” removed) or “from pc” playback.

Edit:

That is actually how they sound on the saber when “decoded from” talkie format!

Not sure if anybody here remembers but me, but 7 years ago we used to use the “military style” errors.

Here is the change:

It also shows what sounds we used to use.

1 Like

Fair enough then. (sounds good :slight_smile: )

1 Like

I was not around lightsaber, let alone ProffieOS, back then.
These errors “look” very nice, I’ll try to have a “listen” tomorrow. What is “PROGMEM” ?

Edit: what OS version was that ?

It’s an Arduino thing for specifying how to store data in memory.

https://docs.arduino.cc/language-reference/en/variables/utilities/PROGMEM/

1 Like

1.278 if I’m reading it right.
This before proffieos was on github, so I used CVS version numbers at that time.

  1. people who just want a specific set of presets to fit as the OS advances

I found that in the last jump I was one preset short (I have less than ten, but with fully built out Fett263 styles and customization). Ultimately I replaced my 2.2 board with a V3 and now have tons of unused memory.

1 Like

I listened to them, they were just named “military style” (spSOMETHING) but unfortunately they sound the same as the current ones (talkie_something_15). Just looking at the size of the code, the old ones seem shorter. Why were they changed from spSOMETHING to talkie_something_15 ?

If you want to hear both the old and current ones (recorded with my phone), here are some of them (each words will play twice):



Can anybody hear a difference ?

Then I did a few compile size check with both styles of talkies:

current talkie_15 style format:
Sketch uses 247584 bytes (94%) of program storage space. Maximum is 262144 bytes.
old spMILITARY style format:
Sketch uses 246848 bytes (94%) of program storage space. Maximum is 262144 bytes.
my version (with No.S.D, No.F.O.N.T & F.O.N.T.Error, no other talkies included):
Sketch uses 242184 bytes (92%) of program storage space. Maximum is 262144 bytes.
my version (with No.S.D only):
Sketch uses 241744 bytes (92%) of program storage space. Maximum is 262144 bytes.
with DISABLE_TALKIE:
Sketch uses 237288 bytes (90%) of program storage space. Maximum is 262144 bytes.

I is probably not worth it to keep the talkie code (4456 bytes) for just one Talkie Error message only. Unless I can shrink that too, however I am unable to understand or read that part of the code.

@profezzorn would you like me to delete my sound recordings in this whole thread ?

These are the ones we changed to which are basically identical to the ones we have now.
Did you listen to the ones we changed from?

The reason for the change is simple: the available sounds were too limiting, so I recorded new ones. The “15” refers to the symbol rate, which is higher in the sounds I recorded to make it easier to hear what I’m saying. Unfortunately higher symbol rate also means that they take up more memory.

no

We could replace it with a simpler algorithm, like 4-bit u-law if all we have to do is to encode a single sound. The sound would become bigger though, so it might not pay off. (With 4-bit u-law, one second of audio would use up 4000 bytes.)

What was your process to make them?

Recorded, did a little filtering, then ran it through python_wizard if remember correctly.
I had several failed attempts at first until I realized that having aclean sample with no background noise helps a lot. (And also increasing the symbol rate.)

Oh right, that is not how I understood the intent of your link. I thought you were pointing at the “old” spLOWBATTERY, so no

I didn’t listen to what was before that. But just for the fun of it, I will. These are the ones I can see:

talkie.Say(spABORT);

talkie.Say(spLOW);
talkie.Say(spPOWER);

talkie.Say(spPLEASE);
talkie.Say(spCONNECT);
talkie.Say(spS);
talkie.Say(spD);
talkie.Say(spUNIT);

talkie.Say(spBANK);
talkie.Say(spOPEN);
talkie.Say(spFAILURE);

Did I miss any ? They will not be as intuitive to understand what they mean (except low power) but I can easily imagine that they would sound clearer.

With that point of view in mind with what there was before the change 7 years ago, yes I completely understand.

But my question still stands, why change from spLOWBATTERY to talkie_low_battery_15

From my example above:

The first sound you hear is spSOMETHING, the second is talkie_something_15. I personally can’t hear any difference. In other words, why was the higher symbol rate introduced ?

4000 bytes is still a lot of space for just one sound. IMHO

Before continuing the talkie subject/potentially replacing “talkies” with some *.wav files, I think I need to better understand the FONT_PATTERN "*;common" define behavior and usage/application. I think it would be pertinent to have that discussion somewhere else than here. What would be best ? In it’s own new thread or in the ProffieOS 8.4 beta (call for testers!)

  1. words_with_undescores is easier to read than WORDSWITHUNDERSCORE
  2. the “15” refers to the higher symbol rate
  3. I wanted the created clips to be different from the found clips to avoid any potential collisions.

If I remember correctly, the spSOMETHING (for the ones that I created) also had high symbol rate, it just wasn’t specified anywhere.

It is. 4-bit u-law might not be the right solution.

I think the 8.4 beta thread is quite long already, so either here in a new thread.
I don’t think FONT_PATTERN is really going to help with this though.

you could also have used WORDS_WITH_UNDERSCORE, but I understand. Nobody likes to be SHOUTED at. :stuck_out_tongue_winking_eye:

Right, so the “talkie_” & “_15” parts from “talkie_something_15” don’t “do” anything, they are just your naming convention.

&

Ok, but if you compare the content of (for example):

const unsigned char spLOWBATTERY[]             = {0x80,0x02,0xEC,0x4F,0x3D,0x5D,0x2E,0x8A,0xF1,0x1C,0x96,0x0E,0x59,0x22,0x66,0x7E,0x9D,0x3B,0x2D,0x99,0xD8,0x8A,0x49,0x8E,0x8E,0x94,0xC2,0x60,0x26,0x38,0x47,0x70,0x0B,0x63,0x6C,0x93,0x19,0x23,0x25,0x8C,0xA9,0x8C,0x67,0x8C,0xA4,0x30,0xA4,0x52,0xD9,0x34,0x12,0x02,0x5F,0xCA,0x64,0xCA,0x48,0x08,0x6C,0x2D,0x93,0xC9,0x20,0x2E,0x30,0x3D,0x55,0x36,0x8B,0xB8,0xC0,0x0E,0x17,0x9D,0x0E,0x62,0x02,0x33,0x9D,0x6D,0x2B,0xB4,0x0A,0xF5,0x0C,0xD6,0xAD,0xC0,0x22,0x32,0x3D,0x0C,0xBB,0x07,0xA3,0x84,0xE5,0x34,0x8C,0x8A,0x04,0xA0,0x22,0x17,0xC2,0x3D,0x2D,0x50,0x89,0x62,0xF2,0xC8,0xF4,0xC0,0x2D,0x8A,0x59,0x3B,0x32,0xC5,0x8C,0x28,0x25,0x6D,0xEF,0x30,0x33,0xA2,0x9C,0xB5,0xA2,0xC3,0x74,0x8B,0x52,0x96,0xCE,0x0A,0x29,0x25,0x8A,0x49,0x33,0x33,0xC4,0xB8,0x24,0x6B,0x2D,0x1E,0x0F,0xE5,0x92,0x18,0x29,0x6D,0xCC,0x94,0x49,0x53,0xC6,0xD6,0xD1,0x88,0x2A,0x4B,0x05,0x47,0x5B,0x4A,0xAA,0x2C,0x66,0x1C,0x6B,0xA9,0x20,0xF2,0x98,0x70,0xAC,0xA5,0xB0,0x28,0x62,0xC0,0x89,0x96,0x20,0xAA,0x4C,0x96,0x32,0x47,0x03,0xAB,0x32,0x19,0xF2,0x5E,0x35,0xCC,0xAA,0xA8,0xB0,0xBB,0x55,0x28,0xA9,0xA2,0xC4,0xC9,0x62,0x6A,0xA8,0xCC,0x02,0x36,0x9A,0x90,0xA1,0x32,0x70,0xDC,0x48,0x62,0x06,0x00,0xF0};

&

const unsigned char talkie_low_battery_15[]    = {0x00,0x80,0x02,0x94,0x87,0xBD,0x5C,0x0E,0x8A,0xD1,0x6A,0xD6,0x72,0xD9,0x24,0x21,0xF9,0x8C,0x33,0x2D,0xB1,0x98,0xDB,0x0D,0xE9,0x8C,0xC4,0x62,0x69,0xD6,0x68,0x47,0xB0,0x8B,0x02,0xAD,0x36,0xAD,0xC4,0x21,0x0C,0x7A,0x92,0x63,0x4C,0xA7,0x30,0x86,0x36,0xE9,0x11,0x9C,0xC2,0x18,0xDB,0x64,0xC6,0x48,0x0A,0x53,0x2A,0xE3,0x99,0x20,0x29,0x8C,0x25,0x55,0xB6,0x8D,0x84,0x20,0xA4,0x36,0xD9,0x34,0x12,0x02,0x9F,0xCB,0xB9,0xD3,0x88,0x0B,0x7C,0x4D,0x95,0x29,0xA3,0x2E,0xB0,0x2D,0x4D,0x26,0x8D,0x98,0xC0,0xD4,0x36,0x9E,0x08,0x62,0x02,0xD3,0x53,0x64,0x33,0x88,0x09,0xEC,0x08,0x91,0xA9,0x22,0x26,0xB0,0xD3,0x44,0xA7,0x83,0xA8,0xC0,0x4E,0x67,0xDB,0x0A,0xAC,0x42,0x3D,0x82,0xED,0x32,0xB4,0x08,0xD5,0x0C,0xD6,0xAD,0xC0,0x2C,0xD2,0xC3,0x95,0xA6,0x0B,0x93,0xD8,0xD6,0x34,0xA8,0x1E,0x8D,0x12,0x9A,0xCB,0xD9,0xD3,0x32,0x00,0x00,0x11,0x83,0x71,0x95,0xF4,0xC8,0x26,0x72,0x21,0xDC,0xD3,0x02,0xA7,0x28,0x26,0xF7,0xC8,0x08,0x5C,0xA2,0x98,0xB5,0x22,0xD2,0x48,0x89,0x62,0xD6,0x8E,0x4C,0xB1,0x25,0x4A,0x59,0xDB,0x3B,0xCC,0xB4,0x28,0x27,0x2D,0xEF,0x30,0xD3,0xA2,0x9C,0xB5,0xA2,0xC3,0x4C,0x89,0x52,0x96,0x8A,0x0E,0xD1,0x25,0x4A,0x45,0x3A,0x33,0xA4,0xA4,0x28,0x66,0xCD,0x8A,0x10,0xEA,0xE2,0x14,0xB5,0xAC,0x43,0xB4,0x49,0x8A,0x92,0x96,0xB6,0x48,0x2E,0x89,0x41,0xC2,0x56,0x4D,0x9B,0x24,0x46,0x2A,0x1D,0x97,0xA4,0xD2,0x94,0xB1,0x6D,0xD4,0xA2,0x4A,0x53,0xC1,0x96,0xD1,0x0A,0x22,0x4B,0x05,0x47,0x5B,0x23,0x88,0x2C,0x66,0x1C,0x6B,0x89,0x21,0xB2,0x98,0x71,0xAC,0x35,0x06,0xCB,0x43,0xC6,0xD5,0x96,0x42,0x2C,0x4F,0x11,0xDB,0x87,0x8B,0xB0,0x22,0x06,0x5C,0x2F,0x0E,0xC2,0xCA,0xE8,0xA8,0x73,0x38,0x88,0x28,0x93,0xA5,0xCC,0xD1,0xC0,0xA2,0xCC,0x96,0xBC,0x56,0x0D,0x93,0x2A,0x1A,0xAC,0x19,0x16,0x4A,0xAA,0xA4,0xB0,0xA6,0x55,0x28,0xA9,0x82,0xA2,0xE9,0x60,0xA9,0xA8,0x8A,0x12,0x27,0x8B,0xA9,0xA1,0x32,0x49,0xD8,0x28,0x82,0x87,0xCA,0x2C,0x60,0xA3,0x89,0x1D,0x2A,0x3C,0xC7,0x8D,0x24,0x66,0x00,0x00,0x00,0xF0};

they are different & talkie_low_battery_15 is longer yet they both sound the same IMHO. Why not re-use the “value” of “spLOWBATTERY” and just rename it “talkie_low_battery_15” ? BTW, this is not a critique, I am just trying to understand “what happened” or “why it happened”.

How about the “same-ish” algorithm as the one in use but simplified and optimized to “only be able to play” “the best possible” rate/energy/… for the one and only talkie that would remain for sd card missing/not found/insert SD … (if we choose to go that route). Again I have no idea how to do that, but would that be possible ? And would it reduce the size of the talkie code ?

I will start a new thread because I suspect that FONT_PATTERN can’t do what I expect it to do and that would make the FONT_PATTERN discussion irrelevant for the talkie enhancement.

Unfortunately I do not remember, it’s just been too long.
It’s possible that these first updated sounds didn’t have the increased symbol rate.
It’s also possible that the reason that the *_15 sounds originally sounded better isn’t there anymore, in which case moving back to the original symbol rate would be fine.

I’m not sure. The talkie code is fairly simple, so it’s a bit surprising to me that it takes up 4k. Modifying and designing new audio encoding algorithms from scratch is not something I really know how to do though.

alright, I redid these.
here’s recorded results and the code

const unsigned char talkie_voice_pack_15[] = {0x22,0x6e,0x24,0xc8,0x53,0xed,0xa8,0x58,0x96,0xca,0x50,0x8d,0x2b,0x62,0xf9,0x5c,0x2d,0xb2,0xa9,0x88,0xe5,0x4b,0x15,0xcf,0xa6,0x2a,0xd2,0x4f,0x4d,0x2b,0xd3,0xba,0x40,0x3e,0x2d,0x4f,0x77,0x17,0x02,0xbd,0xac,0xbc,0xc3,0x5a,0xf2,0x75,0xf7,0x8e,0x29,0xb1,0xc9,0x0b,0x41,0xa6,0x22,0xa5,0x24,0x2f,0x39,0xec,0x1e,0xa7,0x1d,0xbc,0x68,0xa9,0xa6,0x83,0x4e,0xf0,0x5b,0x30,0xf6,0xcc,0xb8,0xee,0x1c,0xba,0xd8,0xdc,0xe3,0x0a,0x60,0xda,0x61,0x06,0x1c,0x33,0x86,0x80,0x25,0x4b,0x11,0xb0,0x64,0x28,0x02,0x96,0x48,0x13,0x7f,0x2b,0xa1,0x99,0x1e,0xdb,0xc8,0xb5,0x6a,0x74,0x55,0x53,0xe7,0xd7,0x2a,0x95,0xd5,0x4d,0x52,0x90,0x0b,0x4f,0x8c,0xcb,0x6e,0x51,0x2a,0x32,0xb1,0x61,0xa5,0xc5,0xa9,0xca,0xd4,0x86,0xd9,0x12,0xc7,0x62,0x63,0x6b,0x72,0x4a,0x1c,0x93,0x6e,0x4e,0x52,0x29,0x71,0x49,0xb4,0xd9,0x21,0xc5,0x25,0xb5,0x72,0x59,0xa7,0x64,0x15,0x97,0x22,0x59,0x55,0x76,0xd8,0x5f,0x92,0x46,0x67,0xc5,0x15,0x7f,0xcd,0x66,0x95,0x11,0x29,0x44,0x5d,0x27,0x9b,0x5b,0x1c,0x95,0x0f,0x59,0x12,0x21,0x76,0xd0,0x5f,0xad,0x88,0xaa,0x88,0x84,0x07};
const unsigned char talkie_version_15[] = {0x26,0xae,0x24,0xc8,0x43,0xed,0x84,0xc4,0x05,0xcf,0x74,0xb3,0x93,0x12,0xdf,0x68,0x2d,0x2b,0x62,0x4a,0xed,0xa4,0x75,0x4f,0x53,0x21,0xd3,0x53,0x36,0xcc,0x2c,0xba,0xdc,0x54,0x3e,0xb3,0x30,0x14,0xf2,0x90,0xf0,0x22,0x22,0x44,0xc8,0x63,0xc2,0xcd,0x88,0x90,0x21,0x0f,0x91,0xba,0xc3,0x23,0x95,0xbc,0x15,0x11,0x35,0x6d,0x5a,0xb2,0x91,0xdb,0xd5,0x44,0x96,0x03,0x66,0xad,0x74,0xc0,0x2e,0x5d,0x06,0x58,0x6d,0x2a,0x25,0x43,0xb2,0x47,0x47,0xcb,0x92,0x26,0xe5,0x91,0x55,0x15,0x4b,0x16,0x8d,0x47,0x54,0x9a,0x4c,0x79,0x51,0xec,0x9e,0x1e,0x39,0x65,0x49,0x88,0x6b,0x44,0xed,0x90,0x45,0xa1,0xa1,0x1e,0x75,0x42,0xe6,0xb9,0x66,0x44,0x34,0x09,0x99,0x95,0x9a,0x9a,0xdd,0xc4,0x65,0x41,0xb3,0x53,0x54,0x52,0x95,0x17,0x23,0x4e,0x66,0x96,0xe0,0x01};
#ifdef ENABLE_DEVELOPER_COMMANDS
  bool Parse(const char *cmd, const char* arg) override {
    uint32_t rate = 0;
    if (!strcmp(cmd, "say") && arg) {
      if (!strcmp(arg, "vpnf")) {
        Say(talkie_voice_pack_15, 25);
        Say(talkie_not_found_15, 15);
      return true;
      }
      if (!strcmp(arg, "eivp")) {
        Say(talkie_error_in_15, 15);
        Say(talkie_voice_pack_15, 15);
        Say(talkie_version_15, 15);
      return true;
      }
    }

Serial monitor:
say eivp
say vpnf

2 Likes

The attached “*.wav” sound much better than before, where they recorded from “being played from your saber” to a recording device, than posted here ? Or were they turned from your software directly into .wav ?

I have not yet tried to play the talkie codes directly from my saber but I am hearing “voice_hack” instead of “voice_pack” from the .wav you just posted. “version” seems clear enough now.

I am “AFS” (Away From Saber) till Sunday late afternoon/early evening.

played from saber speaker into microphone into Audacity.

1 Like