Shop OBEX P1 Docs P2 Docs Learn Events
Prop2Play - audio player for a P2-EC32 [0.33] - 1024x600 - Page 5 — Parallax Forums

Prop2Play - audio player for a P2-EC32 [0.33] - 1024x600



  • @pik33 said:
    To do: keyboard autorepeat.

    Oh yea, that's a kinda a missing feature. PS/2 keyboards have auto-repeat internally, USB only reports currently held keys. OTOH, you can easily implement it:

    • If you get a key-down event, store it and reset the timer to the initial wait value
    • If you get a key-up event matching the stored down event, delete the stored event
    • If timer expires while a down event is stored, repeat it, reset timer to repeat value

    The initial wait and repeat times being different is important to making it feel good.

  • pik33pik33 Posts: 2,358
    edited 2023-05-09 12:09

    Yes, I have this already done for a Pi so I only have to copy this here. The mouse double click is already implemented in the player.

  • Wuerfel_21Wuerfel_21 Posts: 4,674
    edited 2023-05-09 12:19

    Also, I see your SPCcog is still at V1.0. Update to 1.2 to fix some sample clipping/precision issues (mostly in modern modules)

  • pik33pik33 Posts: 2,358

    Now I have to find where I hacked SPCCog to get oscilloscope data to be displayed...

  • pik33pik33 Posts: 2,358
    edited 2023-05-09 13:11

    There is a standard problem with the spccog : UTF16

    Edit: converted, hacked, upgraded, now the player uses 1.2. This version has several lines added that sends the data to the prop2play oscilloscope. However play timer doesn't run, I have to find why. And enable VU bars

  • Wuerfel_21Wuerfel_21 Posts: 4,674
    edited 2023-05-09 13:13

    Oh yeah, the old usual. Just convert to UTF-8, it will be fine.

    Allegedly prop tool's getting deprecated, maybe we can finally have UTF-8 as the standard.

    EDIT: Weird tangent: the Tortoise Git diff GUI can compare files that are encoded differently. How interesting.

  • pik33pik33 Posts: 2,358


    Upgraded SPCcog to 1.2
    Added keyboard autorepeat - important for keys 7,8 (sample rate control by keeping the key pressed)
    Several bugs fixed

  • pik33pik33 Posts: 2,358

    Fixed too long timeout for mouse double click, that was very annoying. There is only changed .bas and binary in the zip

  • pik33pik33 Posts: 2,358
    edited 2023-05-19 10:25

    Preliminary mp3 support. To make a proper mp3 support I still have to do a lot of things, but now it plays, although the samplig frequency is not yet adjusted as it should be.
    The binary uses hdmi at p0, av at p8, usb at p16

  • pik33pik33 Posts: 2,358

    This binary has heap size 16k instead of 8k. Mp3 files still play; reduced heap size made problems with displaying file lists

  • pik33pik33 Posts: 2,358
    edited 2023-05-23 10:16

    There are still a lot of bugs in mp3 related player code to fix.
    And I have a problem now with very long file names that cannot open. As i can remember, there is a restriction somewhere in the player that has to be raised or removed, but now the palyer crashes while trying to open the file with too long file name.
    Also, the Flexprop's LFN fails on the files that have non-standard (in this case Polish) letters in their names. It then escapes to a short file name with ~ in it.

    But there are also a lot of possible garbage in mp3 files themselves.

    The code that skips id3v2 based on its length field was not good enough for several mp3 files I am using to test the player. After the proper id3v2 there was a lot of zero bytes left in the file before the first mp3 frame in the file. (and these id3 tags can be gigantic.... the player surprised me with the text "tag detected, size=1.001705e+06")
    So, the version I attached here, has an enhanced algorithm that if there in no mp3 frame header and also no ID3 tag, it searches for the first FFFx or FFEx in the file. It does it also after the id3v2 tag.

    Edit: yes, I restricted the file name length in the player... 640 kB 38 characters should be enough for all.... That is not true for these mp3s.

  • @pik33 said:
    (and these id3 tags can be gigantic.... the player surprised me with the text "tag detected, size=1.001705e+06")

    A megabyte of tag? lol. Let me guess, cover art in too high resolution / quality?

  • pik33pik33 Posts: 2,358
    edited 2023-05-23 19:12

    It seems the picture is 500x485. Somewhere in the future maybe I will write a proper id3 decoder; now it only reads the length, then skips the tag only to find a (EDIT: hundreds of ) kilobyte(s) of zero bytes after. I don't know who and with what coder coded this file as it of course came from the internet.

    Edit: The picture is 1356x1314px :) and 976 kB

    It seems I need a mp3 cleaner tool. While skipping a kilobyte of zeros is fast enough, searching a header 200 kB after the end of ID3 - someone inserted over 200 kB of zeros there - byte by byte is too long.

  • pik33pik33 Posts: 2,358

    Another glitch.... These mp3s can have "," in their file names. Then the line

    input #7,filename$ 

    stops inputting on this "," and the result is the truncated filename... Input has to be replaced by get....

  • pik33pik33 Posts: 2,358
    edited 2023-05-23 15:02

    File name length limit raised from 39 to 78 chars
    Zeros after id3tag now skipped much faster.
    This version is now much more usable for mp3 files playing.

    The zip contains changed player.bas and a binary, the rest is unchanged from 0.31

    Directories needs rescanning (R key) after upgrade from previous versions. I have to add a version tag to directory cache files to avoid this.

  • pik33pik33 Posts: 2,358
    edited 2023-06-14 11:26

    Fixed several bugs and changed the resolution to 1024x600. Several more pixels made a place to display for example long mp3 file names (to do, now they are simply empty)

    Edit: a modified video driver added. The rest of the code base is unchanged from the file at the post #128

  • pik33pik33 Posts: 2,358
    edited 2024-05-23 11:31

    There was a GUS mentioned in a console emulation topic.

    As this is not related to this topic, let's continue here.

    I found a .pat file format description:

    The GF1 Patch files are multipart sound files for the Gravis Ultrasound
    sound card to emulate MIDI sounds in high quality. Each Patch can consist
    of many samples (for example, a string ensemble consists of Violin, Viola,
    Cello, Bass) which are played depending on the note to play. A patch can also
    contain a part to be played before the loop and a part to be played after
    the tone has been released.
    OFFSET              Count TYPE   Description
    0000h                  12 char   ID='GF1PATCH110'
    000Ch                  10 char   Manufacturer ID
    0018h                  60 char   Description of the contained Instruments
                                     or copyright of manufacturer.
    0054h                   1 byte   Number of instruments in this patch
    0055h                   1 byte   Number of voices for sample
    0056h                   1 byte   Number of output channels
    0057h                   1 word   Number of waveforms
    0059h                   1 word   Master volume for all samples
    005Bh                   1 dword  Size of the following data
    0060h                  36 byte   reserved
    Following this header, the instruments with their headers follow.
    An instrument header contains the name and other data about one
    instrument contained within the patch.
    OFFSET              Count TYPE   Description
    0000h                   1 word   Instrument number. ?Maybe the MIDI instrument
                                     number?. In the Gravis patches, this is 0, in
                                     other patches, I found random values.
    0002h                  16 char   ASCII name of the instrument.
    0012h                   1 dword  Size of the whole instrument in bytes.
    0016h                   1 byte   Layers. Needed for whatever.
    0017h                  40 byte   reserved
    About the patch, I don't know anything. Maybe somebody could enlighten me.
    Each patch record has the following format :
    OFFSET              Count TYPE   Description
    0000h                   7 char   Wave file name
    0007h                   1 byte   Fractions
    0008h                   1 dword  Wave size.
                                     Size of the wave digital data
    000Ch                   1 dword  Start of wave loop
    0010h                   1 dword  End of wave loop
    0012h                   1 word   Sample rate of the wave
    0014h                   1 word   Minimum frequency to play the wave
    0016h                   1 word   Maximum frequency to play the wave
    0018h                   1 dword  Original sample rate of the wave data
    001Ch                   1 int    Fine tune value for the wave
    001Eh                   1 byte   Stereo balance, values unknown**
    001Fh                   6 byte   Filter envelope rate
    0025h                   6 byte   Filter envelope offse
    002Bh                   1 byte   Tremolo sweep
    002Ch                   1 byte   Tremolo rate
    002Dh                   1 byte   Tremolo depth
    002Fh                   1 byte   Vibrato sweep
    0030h                   1 byte   Vibrato rate
    0031h                   1 byte   Vibrato depth
    0032h                   1 byte   Wave data, bitmapped
                                       0 - 8/16 bit wave data
                                       1 - signed/unsigned data
                                       2 - de/enable looping
                                       3 - no/has bidirectional looping
                                       4 - loop forward/backward
                                       5 - Turn envelope sustaining off/on
                                       6 - Dis/Enable filter envelope
                                       7 - reserved
    0033h                   1 int    Frequency scale, whatever that means
    0035h                   1 word   Frequency scale factor
    0037h                  36 byte   Reserved

    However it seems to be flawed and lacks detailed informations.

    I made a simple tool to decode the .pat file using this format and there is garbage generated. I managed to "repair" this, changing offsets, etc, so now I can find proper wave data... etc.

    Now, starting from "original sample rate".. it seems still to be garbage. And these 6 bytes filter data... what are these?

    To use these patches for playing midi files, a lot of reverse engineereing has to be done... or maybe someone has an access to better .pat file format description?
    In good, old times I had a GUS registers map/description. I don't know if I can find it now...

  • pik33pik33 Posts: 2,358
    edited 2024-06-07 13:20

    I managed to find this pdf. It seems to be from the original GUS SDK. There are GUS registers and .pat format described here. It seems the PDF is good enough to make a GUS emulation possible.

  • roglohrogloh Posts: 5,283

    P2 GUS emulation sounds interesting. Could be useful for MIDI synthesizer projects with wavetable samples stored in external memory.

Sign In or Register to comment.