Higher resolution FPRs

[phlash]

Hi Olivier, firstly many thanks for this excellent work :smile:

I have been using this code to convert and render some MIDI files, and found it useful to have more than 86 segments on a disc to retain good note timing. I have also made the MIDI import a little more robust on transposing missing notes..

My changes are here in my fork, I don't know if you are interested in including them?

[odrevet]

Thanks your your contributions.

In which use cases do fisher price records have more than 86 segments ? Did you print some records with more thin pins ? Could you provide a .fpr so I can properly test this feature ?

The commit "support variable beat counts in FPR file" (26aa05f63898f03b9d33c671c83860ee1cb24ad8) needs some adjustments, as sometimes I have records with a few blanks at the end (FPR_SEC_BETWEEN_BEATS could be given as parameter or added in the fpr)

I also see you included write.scad (I did managed to make it works, but the 3D printer could not properly render so removed it, I forgot to remove the import in the generated scad)

[phlash]

In which use cases do fisher price records have more than 86 segments ? Did you print some records with more thin pins ? Could you provide a .fpr so I can properly test this feature ?

I have been experimenting with importing various MIDI files, while retaining good timing. This usually means adjusting the imported BPM until the shortest gap between notes in the MIDI file corresponds to a single beat_index in the FPR. As a result it usually takes more than 86 beats to fit in a 25-30sec piece of music (one rotation of a disc). I attach my current experimental files (MIDIs from musicboxmaniacs,com and resulting FPRs). I should note I have not tried to produce any physical discs yet!

The commit "support variable beat counts in FPR file" (26aa05f) needs some adjustments, as sometimes I have records with a few blanks at the end (FPR_SEC_BETWEEN_BEATS could be given as parameter or added in the fpr)

True, this assumes the FPR file will always contain a whole rotation of beats, whereas some may need extending. Perhaps a command line switch to enable my new behaviour would suffice?

I also see you included write.scad (I did managed to make it works, but the 3D printer could not properly render so removed it, I forgot to remove the import in the generated scad)

I did, since I spent about 2 hours bringing it up to date for OpenSCAD 2021+ and was unable to find an original repository to submit fixes to (it's possibly dead code?)

export.zip

[odrevet]

With your implementation, the more notes (or "beats") there are, the more FPR_SEC_BETWEEN_BEATS is smaller because the pins on the record would be less spaced-out, is this correct ? In this case I would need to test how practical this scenario is with a physically printed disc (e.g, the minimal spacing between pins, jamming, and so on).

I think the best option is to merge 26aa05f63898f03b9d33c671c83860ee1cb24ad8 "support variable beat counts in FPR file" and dad17f5d87fc9cf5892285a8a6a531815f2d89c9 "support variable beat counts when mastering to SCAD" into a branch like "hi-res-fpr". Except for the changes in input.py : if record and self.beats_count != record.beats_count: this line of code controls the width of the display windows, the more wider it gets, the more it might crash the app if it gets larger than the display terminal (Curses is not responsive friendly). This is not a problem if you want to support more than 86 notes thought, as the display window is scrollable.

39bfb989f2a90ab0b3b70cbf32b0ecc43f95e4b2 "transpose all missing notes when importing MIDI, verbose info to help…" could be merged directly into master

For 7c1314ec87e0361f2ca243cff233be83cf7dcb4b "updated Write.scad implementation for OpenSCAD2021+", I did not yet reviewed/tested it but this seems like an interesting update ! (could also be included in a branch)

You can do pull request, I don't known how to cherry pick each commit into a branch or the master branch but let's try that anyway

[phlash]

With your implementation, the more notes (or "beats") there are, the more FPR_SEC_BETWEEN_BEATS is smaller because the pins on the record would be less spaced-out, is this correct ? In this case I would need to test how practical this scenario is with a physically printed disc (e.g, the minimal spacing between pins, jamming, and so on).

Yep - with this approach it's possible to create unprintable / unplayable SCAD/STL files. To solve this sensibly, I should include some design rules on minimum spacing for pins in any one track and both the tracker and FPR->SCAD conversion should warn about violations (and possibly stop). For a first trial I just eyeballed the resulting model..

Except for the changes in input.py : if record and self.beats_count != record.beats_count: this line of code controls the width of the display windows, the more wider it gets, the more it might crash the app if it gets larger than the display terminal (Curses is not responsive friendly). This is not a problem if you want to support more than 86 notes thought, as the display window is scrollable.

Ah ok - I did not realise the window scrolled (no indication), so simply bodged that in to display everything in the FPR file, mea culpa! I'll look at a way to show content can be scrolled :smile:

You can do pull request, I don't known how to cherry pick each commit into a branch or the master branch but let's try that anyway

I'm happy to separate the parts into PRs: first the import transposition changes (as they are ok), then Write.scad fixes, and then the scroll indicators. When I'm happy with the FPR resolution changes and design rules I'll PR those.

[odrevet]

Among other things, I've updated the display so it's more dynamics : the scroll was enabled only if the opened fpr has more than 86 beats ; Now the size of the display matches the size of the terminal, you wont have to deal with it for your implementation of hi-res FPR (The 86 beats limit currently still apply when the scad is created).

There is also a differance between an empty note (cyan and black stripes) and no data (no color), the beat count to compute the tempo could be how many beats with or without notes (size of a line/track in the .fpr) instead of the index of the last note:

For example, the fpr:

+-----
------
---+--
------

could have 6 beats (number of - or + on a track) instead of 4 (index of last note) This would solve the problem of blanks notes to slow down the tempo

[phlash]

Cool, thanks for the ping! I've been away from this for a few days - my display changes to show scroll indicators and support scrolling by 'page' (whole screen width) are quite extensive, but still possibly useful - I'll see what a merge looks like!

[odrevet]

Expect merge conflicts (sorry for that, you should pull and merge asap) input.py has been renamed ui_curses/display.py (should be picked up by git)

[rcamp5656]

I have been working on this too mainly two things, one is a batch file to support all features of your programs, the other and more interesting is a qb64 program that will include all python scripts.

Russ Campbell

[rcamp5656]

I have lots of midi files for testing.... I can send you a link to my private server with all the files needed........ Russ