Open albertms10 opened 5 months ago
Aproximació 1 de la taula de Registres sonors. Queden exclosos acoblaments, trèmols i altres efectes que no produeixen so directament.
{
nom: string,
peus: Peu | array[array[Peu]], // nota 1, 2
tessitura: array[Tessitura], // nota 3, 8
és_un_ple: bool, // nota 3
manquen_detalls: bool // nota 3
registre: enum{SENCER, BAIXOS, TIPLES, BAIXOS_I_TIPLES} // nota 4
accionador: enum{TIRADOR, PLAQUETA, LLISCANT, PERMANENT} // nota 5
joc: enum{LLENGÜETA, FONS, MIXTURA, ALTRES} // altres significa gaites, ocellets, tambors, etc.
sub_joc: enum{LLENGÜETA_LLIURE, RESSONADOR_CURT, HARMÒNIC, BORDÓ, FLAUTA, PRINCIPAL, GAMBA, QUINTANT, ONDULANT, MUTACIÓ} // nota 10
absent: bool,
absent_comentari: string,
és_transmissio: bool,
transmissio_de: integer // nota 6
és_extensio: bool,
és_extensió_de: integer // nota 6
té_préstecs: bool,
presta_de: integer // nota 6
presta: Tessitura,
en_batalla: bool,
batalla: Tessitura,
en_façana: bool,
façana: Tessitura,
observacions: string // nota 7
}
Notes:
Peu
pot ser una entitat analitzable amb el següent format: un nombre enter, una cadena de caràcters formada per un nombre enter seguit d'una fracció o una cadena de caràcters formada per una fracció. Exemples: 8
, "2 2/3"
, "1/3"
.
La major part de les vegades, els registres tenen només una rengla i no repeteixen. Per això, és convenient que aquest camp pugui ser alhora un Peu
o una llista de llistes de Peus
. No proposo cap format entremig perquè dóna lloc a confusions.
Com que hi ha la possibilitat que no se sàpiga l'extensió (per exemple, a on talla el baixó i el clarí), utilitzar la tessitura com a clau resulta inadequat. També resulta inadequat adjuntar la tessitura en els elements de més nivell de la llista anterior descrita, ja que poden ser desconeguts. Per això proposo separar-la, cobrint així tots els casos de manera senzilla:
manquen_detalls
). Per què ha de saber la màquina que manquen detalls? Per mostrar a cada pàgina dels orgues quines informacions manquen o estan incompletes per si algú s'anima a completar-les. I, abans de tot, no he trobat la manera que, amb les dades proporcionades, la màquina pugui decidir si falten o no dades. Hi ha massa casos i se solapen. M'explico:
peus: [[8],[4]], tessitura: null
. Aquí, la màquina veu que hi ha dues repeticions (la llista de peus
té dos elements), però no té tessitura. Per tant, manca inventariar la tessitura
. Tanmateix, qui entri les dades haurà de marcar el camp manquen_detalls
. peus: 2 2/3, tessitura: null
. No hi ha manera de saber que falta informació. Per això, cal marcar el camp manquen_detalls
per informar-ho. El camp és_un_ple
s'hauria de marcar, indicant a la màquina que cal mostrar una composició com Déu mana (nota 9). Però com que manquen_detalls
, llavors no es mostrarà. 2
, 1 1/3
i 1
, però no se sap on repeteixen. S'apunta peus: [[2, 1 1/3, 1]], tessitura: null
i es marca el camp manquen_detalls
. Nota pel lector: hi ha plens que NO repeteixen. Cal marcar, tractant-se d'un ple, és_un_ple
. 2 2/3′ | 4′ + 2 2/3′
a la vista, i a la base de dades, peus: [[2 2/3],[4,2 2/3]], tessitura: [C,cs']
. El més probable és que se sàpiga que té una i dues rengles (o dues rengles de cap a fi), però no se sàpiguen quines són i si repeteixen. Segons el que he dit, s'hauria d'anotar peus: 2 2/3, tessitura: null
, però la màquina no sap que falta informació. La persona, sí. El camp manquen_detalls
hauria de ser true
per indicar a la màquina que, efectivament, el que s'ha entrat és incomplet. La representació anterior no permet —o no l'he sabut trobar— especificar el tipus de registre que és. És cert que es pot deduir per les extensions, però si aquestes són desconegudes (com els baixons i clarins), val més afegir el camp sencer
(que és el per defecte): així hom es deslliura de marcar manualment una extensió desconeguda i queda, indirectament, marcada com a dada que manca. A més, es pot calcular més fàcilment el nombre de tubs, sense necessitat de deduir mecànicament dades que estan a mitges. Registres marcats així nom: Bordó, peus: 8, tessitura: [C,cs'], registre: BAIXOS_I_TIPLES
o així nom: Bordó, peus: [[8],[8]], tessitura: [C,cs'], registre: BAIXOS_I_TIPLES
s'haurien de considerar iguals. Si es marca BAIXOS_I_TIPLES
i només hi ha una extensió (null
), llavors manca inventariar la partició del joc. De la mateixa manera, TIPLES
que tenen tessitura null
és incorrecte o manca informació (es podria mostrar una exclamació dient: Ull! hi ha una incongruència!), com BAIXOS
amb tessitura null
i altres combinacions d'aquestes. De vegades, s'ha de permetre l'entrada de dades incorrectes perquè no se sap com és la realitat; sabent això, es pot informar a l'usuari que entra les dades que "potser falta informació o més detall" i informar al navegant de la pàgina que aquelles dades poden ser incorrectes o mancar més detall.
Hi ha orgues que la partició de registres no és la mateixa per a tots els registres. Uns parteixen entre c'
i cs'
i d'altres, per portar la contrària, entre h
i c'
. Per això, val més no col·locar un camp que delimiti el partit en l'àmbit de teclat. Cada registre partit especificarà, a tessitura
, un llista ["C", "cs'"]
. Podrem saber, amb aquest camp, el nombre de tiradors, i, en conseqüència, com representar els talls: |
o bé /
.
És informació extra. Hi ha orgues que disposen de dos sistemes diferents, per tant, no és convenient fixar aquesta propietat en l'àmbit del teclat. Per defecte, tirador
. El més interessant és el permanent
, ja que pot condicionar la interpretació d'algunes obres.
referència a un id d'un altre registre del mateix orgue. Si hi ha un aplicatiu per entrar les dades, és fàcil de fer
calaix de sastre per anotar tot allò que no ha quedat anotat amb els altres camps. Els francesos hi posen, per exemple, qui va introduir tal joc en una restauració o ampliació. Però hi pot anar qualsevol altre particularitat que sigui tan concreta que no valgui la pena tenir un camp específic a la base de dades.
Tessitura
. Una nota o un rang de notes. Si és una nota, la tessitura està compresa des de la nota fins a la nota anterior a la següent tessitura o l'última nota del teclat. Si és un rang de notes, són dues notes separades per un guionet. Les notes, amb notació Helmholtz. Si aquesta notació ens porta problemes pel tractament de cadenes de caràcters que contenen cometes, s'utilitza la notació científica, essent C = C1
.
Disposició de plens com Déu mana:
C 1/2' 1/3' 1/4'
c 1' 2/3' 1/2'
cs' 2' 1 1/3' 1'
c'' 4' 2 2/3' 2'
o bé, girat, però no sé si és correcte, així
C 1/4' 1/3' 1/2'
c 1/2' 2/3' 1'
cs' 1' 1 1/3' 2'
c'' 2' 2 2/3' 4'
Pot ser interessant tenir aquesta informació. Són famílies grans que ens poden ajudar a fer algunes estadístiques i cerques curioses. És un camp opcional i de baixa prioritat.
Estic pensant fer un petit programet amb python
que sigui capaç d'interpretar aquest merder per introduir-li tota mena d'exemples i validar que la definició sigui robusta. Fent-ho, també avançarem en el validador i en els tests unitaris de la pàgina web (traducció de python a JS).
Definició de la base de dades amb PostgreSQL (manca la miscel·lània i una data, però per avui ja en tinc prou)
Més coses:
Més cosetes:
- Pedal ha de ser una taula a part, amb aquestes característiques
- Pedaler còncau/pla
- Radial o paral·lel
Et pots creure que vaig deixar apuntat el mateix fa un parell de nits? 🙃
Totalment d'acord; en essència són teclats, però necessitem reflectir la diferència anatòmica de teclat manual i pedal. Fins i tot, si és un pedal de xampinyons (contres, botons, com a Cadaqués, del qual no conec la nomenclatura tècnica) o de tecles allargades convencionals.
A més, i això aplica sobretot (o només?) a teclats manuals, si és d’octava curta o convencional. Tot i que potser es pot deduir de la mateixa disposició de l’extensió del teclat 🤔 (potser també el pedal de xampis?).
Pots entendre que no hi he pensat fins fa dues nits, també? Vaig afegir l'enumerat {IBÈRIC, ALEMANY, FRANCÈS}
a l'apartat del pedal de la fitxa, és a dir, essent l'ibèric les contres, xampinyons, etc. És discutible si utilitzar el nom ibèric o bé contres, ja que em sento més còmode afegint _C_a la composició en aquest cas i no una I, que amb la tipografia sans serif és un maleït pal (més després dels exemples visuals). Si molt m'apures, tot i que de moment crec que no n'hi ha cap, podríem ampliar l'enumerat amb el terme ITALIÀ
, ja que tenen unes característiques físiques concretes (adjunto foto de l'orgue italià de l'aula 301 de la HMDK Stuttgart):
Un pedaler francès és el que hi havia a Castelló d'Empúries (que ja no hi és després de la restauració) i el que hi ha a Sant Llorenç de Morunys, el qual encara no he actualitzat les fotografies de la web:
Aquest enumerat ens pot ajudar a crear la composició automàticament: decidint si posar una P de pedaler o una C de contres o, fins i tot, F de pedaler francès (que, de moment, només serà aquest de Sant Llorenç de Morunys).
Per l'octava curta no m'hi posaria. Amb el camp d'extensió n'hi ha prou. Crec recordar que l'orgue de la capella de Lepant de la catedral de Barcelona no té octava curta als manuals (C–H normal) però en canvi, el pedal és C,D,E,F,G,A,B,H.
Més cosetes:
Genial, entesos amb les observacions! Tan sols, un parell d'aspectes.
Amb respecte del transpositor:
té un rang de notes. Jo el centraria a c', i el marcaria de la següent manera: [gs–c']: baixa dos tons i no en puja cap.
En desconec casos d'ús reals, però si tan sols es tracta d'especificar "baixa n i en puja m", en lloc d'interpretar rangs de notes, proposo desar els extrems de la transposició en semitons: -4+0
per al cas que proposes, o -6+5
per a "baixa un tritó i puja una quarta".
Sobre les combinacions fixes:
Quins registres/efectes/miscel·lània/acoblaments afecten
En cas que afectin tots els registres, o que n’afectin tots menys tan sols uns quants, podríem idear una mena de Query Language similar a Elasticsearch o JSONSchema:
{ "allBut": ["id-1", ...] }
{ "all": {} }
{ "only": ["id-1"] }
Més cosetes:
Més cosetes:
Ordre de la miscel·lània:
Combinacions fixes (noms, llista o subllistes). Al tooltip ja apareixerà més informació
Combinacions fixes pel II: Flautados, Llenos, Lengüetería, Gran juego
O bé:
Genial; aquest ordre aniria definit consistentment per a totes les taules de disposició de registres, independentment del seu ordre real.
De totes maneres, tard o d’hora haurem d’obrir el 🍉 de la vista en diagrama interactiu, que permetrà conèixer-ne el funcionament d’una manera més realista. Encara dono voltes a com gestionar les dades de posició, ordre, etc. de cadascun dels registres d’un orgue.
En casos on aquesta disposició sigui prou estàndard (com a Barberà o La Pobla de Mafumet, potser), podem tirar d’un sistema predeterminat per dibuixar-ne la consola. Veient que cada orgue és un món —per si encara no havia quedat clar 😅—, per als més complexos el més fàcil serà deixar el pintat d’aquesta disposició a la vista com a encarregada de dibuixar-ho tot. Cada orgue tindria el seu component de disposició personalitzat, en cas que així ho marquem. Serà una feinada important, però podem dedicar l’esforç inicial per als orgues més representatius.
Fins i tot, podem tenir diversos diagrames per cada orgue, com passa amb les dues consoles de Montserrat (que ja veurem si realment té sentit per la seva similitud—tan sols canviaria l’estil).
Estic començant a pensar si prenent totes aquestes dades d’un orgue podem tenir problemes amb els orgueners. És informació certament confidencial, o podria ser de domini públic a tall informatiu o amb fins pedagògics i divulgatius? Potser caldria comunicar degudament que estem duent a terma aquesta recollida, o bé afegir una nota legal sobre la finalitat amb què es comparteix i reuneix tota aquesta informació.
Encara dono voltes a com gestionar les dades de posició, ordre, etc. de cadascun dels registres d’un orgue. En casos on aquesta disposició sigui prou estàndard (com a Barberà o La Pobla de Mafumet, potser), podem tirar d’un sistema predeterminat per dibuixar-ne la consola.
Sí, és un meló (síndria) i encara no veig clar la relació entre la (possible) utilitat davant un públic general i la quantitat de feina que pot portar realitzar aquest projecte. Ves què et dic que ho veig més com un projecte a part de l'inventari (4 o 5 anys vista). Ho veig més com una utilitat per a orgues concrets (comptats amb els dits d'una mà), com una eina divulgativa per explicar què són els registres i com funcionen. Però no ho veig (o encara no he sabut veure-ho) com quelcom per a tots i cadascun dels 300 orgues.
M'imagino la pàgina web amb l'apartat de l'inventari rigorós, amb tots els camps i, si es vol, algun tooltip amb «+ informació». Però també visualitzo un apartat divulgatiu, amb explicacions, glossari, la documentació de com s'ha fet la pàgina i les decisions preses (els melons, degudament tallats, pelats i amb una làmina de pernil de gla, de pota negra), i amb diagrames interactius perquè qui no conegui aquest món pugui entendre com funciona l'orgue (consola, secrets, aire, etc). I dic, una consola, en singular. Potser dues, d'orgues ben diferents. En aquest cas, l'eina pot dibuixar la consola virtual, pintar-hi les notes que s'activen amb un registre, i tots els ets i uts que se'ns acudeixin. Fins i tot, ves què et dic, fins i tot una pantalla tipus «GrandOrgue» on es pugui fer sonar l'orgue amb el ratolí (però sense anar més lluny d'una tecla o grup de tecles). Però limitat a un orgue o orgues molt concrets.
Deixem a la imaginació dels internautes esbrinar com funcionen els 298 orgues restants de l'inventari, incitant-los a anar-los a veure o a sentir-los en concert.
Tenint, doncs, un subgrup de l'inventari molt reduït per realitzar la «consola virtual», ens podem permetre el luxe de:
Com dius tu, cada orgue és un món. Si ja hem tingut problemes per veure com emmagatzemar totes les dades necessàries per l'inventari en una base de dades, no et dic jo els problemes que tindrem per emmagatzemar dades 2D de la posició dels registres. Per què ja et dic jo, no hi ha cap orgue igual i tots tenen alguna cosa que surt de la norma, sobretot els més antics. Fer-ho per tots els orgues ho veig redundant. Els organistes (si realment ho són), amb quatre fotos i la disposició en tenen més que suficient per fer-se la idea. La resta de mortals, no crec que necessitin el diagrama a cadascun dels orgues, havent entès com funciona amb un exemple i tenint les fotografies.
Ei, amb tot això no vull dir que no es faci aquesta pintura a la web; només que si ho vols fer per tots i cadascun dels orgues pot perillar la salut mental de natros dos. Estic aquí intentant que la síndria no s'obri gaire, i m'has vingut amb un ganivet que déu-n'hi-do! Ha, ha, ha.
Estic començant a pensar si prenent totes aquestes dades d’un orgue podem tenir problemes amb els orgueners. És informació certament confidencial, o podria ser de domini públic a tall informatiu o amb fins pedagògics i divulgatius? Potser caldria comunicar degudament que estem duent a terma aquesta recollida, o bé afegir una nota legal sobre la finalitat amb què es comparteix i reuneix tota aquesta informació.
Els orgueners establerts a Catalunya són socis de l'ACO i a l'ACO ja fa temps que es porta dient que s'està fent aquest inventari (diguem que han tingut temps de queixar-se i no han obert boca). A més, les dades que es prenen, a part de la disposició dels plens, són dades que qualsevol organista pot saber des de la consola estant. Fins i tot la disposició dels plens pot ser treta d'oïda (difícil, però es pot). L'inventari pot ser més o menys detallat, però crec (o vull creure) que tot el que es recopila (o que en aquesta issue diem que recopilarem) és informació lliure de secrets i vital en un inventari com cal. No anem a buscar relacions de distàncies en la mecànica, mides de ventalloles, alçada de les canals dels secrets, distància dels llavis de les boques dels tubs, disposició (en mides concretes) dels tubs sobre el secret, etc. Tot això s'hauria de fer quan es fa una restauració o un estudi d'un orgue (en l'àmbit tècnic), però té 0 interès per un públic general i 0 interès per un organista, i tinc un interès nul en recopilar aquesta informació.
Així que, resumint, crec que no ens hem de preocupar gens per aquesta informació.
https://dbdiagram.io/d/ACO-66103a4503593b6b614d8632
Primera versió de l’esquema relacional
```dbml Table registres { id integer [primary key] id_teclat string nom string /** * @type {Record