Closed boblsturm closed 6 years ago
It deliberately only passes the information fields that make sense to render as part of the score. Currently, that's set to M, L, Q and K. https://github.com/tobyspark/folk-rnn-webapp/blob/5cd5c70131ec55c16de884ffed4b0794ec9366cf/folk_rnn_site/folk_rnn_site/models.py#L187
It definitely shouldn't pass S. This is effectively a tune attribution, which should be displayed with the text of the rest of the page. And rendering a long text field as part of the score just looks super screwy. Currently the S text only appears in the full ABC seen lower in the page, in 'create setting', and on download of the ABC. It would perhaps make sense to either render this as one more tune attribution paragraph on the left, or actually create a tune attribution from the S field on submission.
Perhaps it should pass C. Generally, I think metadata text should be rendered with the other metadata on the page. So pulling out any C: field and putting it there would be my vote. But if we were to have it render as part of the score, at least it's a text field that isn't going to e.g. go off the page.
Ah, hang on, you're talking about the ABC view not the rendering of the ABC view.
These are stripped out for display there, for much the same reason that it's to focus on the tune and the metadata is (or should be) shown elsewhere. But also, it's currently tied to what is rendered for the score, so I can't just include more fields there. I can separate that dependency. But again I think the proper thing is to link up S, C with the existing concept and display of tune attributions.
True. What I'm worried about is lost attributions... which I guess is a problem with real tunes as well! As long as it's in the downloaded ABC, shouldn't be a problem.
On 11/07/2018 10:51, Toby Harris wrote:
It deliberately only passes the information fields that make sense to render as part of the score. Currently, that's set to M, L, Q and K. https://github.com/tobyspark/folk-rnn-webapp/blob/5cd5c70131ec55c16de884ffed4b0794ec9366cf/folk_rnn_site/folk_rnn_site/models.py#L187
It definitely shouldn't pass S. This is effectively a tune attribution, which should be displayed with the text of the rest of the page. And rendering a long text field as part of the score just looks super screwy. Currently the S text only appears in the full ABC seen lower in the page, in 'create setting', and on download of the ABC. It would perhaps make sense to either render this as one more tune attribution paragraph on the left, or actually create a tune attribution from the S field on submission.
Perhaps it should pass C. Generally, I think metadata text should be rendered with the other metadata on the page. So pulling out any C: field and putting it there would be my vote. But if we were to have it render as part of the score, at least it's a text field that isn't going to e.g. go off the page.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tobyspark/folk-rnn-webapp/issues/80#issuecomment-404094349, or mute the thread https://github.com/notifications/unsubscribe-auth/AJy6ZK6QbyP1S73Ojp-z-GOf4JpI-vZ-ks5uFbx9gaJpZM4VKoQJ.
-- Cheers. -Bob L. Sturm
Bob L. Sturm, Lecturer of Digital Media School of Electronic Engineering and Computer Science Centre for Digital Music Eng. 111 Queen Mary University of London Mile End Road London E1 4NS United Kingdom http://www.eecs.qmul.ac.uk/~sturm/ https://highnoongmt.wordpress.com https://soundcloud.com/sturmen-1 https://www.youtube.com/channel/UC7wzmG64y2IbTUeWji_qKhA
Yeah we don't lose anything. But you have highlighted an arbitrary division between the ABC info fields and machine folk's TuneAttributions aka notes. I'll make an issue to join them up.
Should not strip out S: field, or C: field.