search

acorgue / web

Web de l’Associació Catalana de l’Orgue
https://acorgue.vercel.app
1 stars 0 forks source link

Slice de la base de dades #5

Open albertms10 opened 5 months ago

albertms10 commented 5 months ago

https://dbdiagram.io/d/ACO-66103a4503593b6b614d8632

Image

Primera versió de l’esquema relacional ```dbml Table registres { id integer [primary key] id_teclat string nom string /** * @type {Record} * * @example - Ple * { * C: ["2 2/3", "2", "1 1/3"], * "c'": ["4", "2 2/3", "2"] * } * * @example - Bordó c'/cs' * { * C: ["8"], * "cs'": ["8"] * } * * @example - Baixons i clarins * { * C: ["4"], * "cs'": ["8"] * } * * @example - Corneta * { * "g|cs'-c'''": ["8", "4", "2 2/3", "2", "1 1/3"] * } * * @example - Corneta * { * "peus": ["8", "4", "2 2/3", "2", "1 1/3"], * "tessitura": "g|cs'-c'''" * } */ tessitura json } Table teclats_registres { id_teclat integer id_registre integer } Ref: teclats_registres.id_teclat > teclats.id Ref: teclats_registres.id_registre > registres.id Table teclats { id integer [primary key] id_orgue integer extensio string } Ref: teclats.id_orgue > orgues.id Table orgues { id integer [primary key] nom string temperament string diapaso string } Table diapasons { id integer [primary key] nota string frequencia double temperatura double id_registre integer } Ref: diapasons.id > orgues.id Ref: diapasons.id_registre > registres.id Table actuacions { id integer [primary key] id_orgue integer id_orguener integer type enum('a', 'b') descripcio string } Ref: actuacions.id_orgue > orgues.id Ref: actuacions.id_orguener > orgueners.id Table orgueners { id integer [primary key] nom string } ```
borgue95 commented 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:

  1. 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".

  2. 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.

    • L'element d'alt nivell de la llista correspon a les repeticions o canvis d'alçada o canvis del nombre de rengles. En definitiva, un punt d'interès en la tessitura del registre (pel que fa a alçades i rengles).
    • L'element de més baix nivell —els components de l'element descrit a sobre— es corresponen a les rengles del registre en aquella secció, ordenades de més gran a més petit —de més greu a més agut—.

  3. 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:

    • En el cas normal i per defecte, la tessitura pot estar buida. Si és buida, se suposa que cobreix tota l'extensió del teclat.
    • En les mixtures i registres amb repetició (com els baixons i clarins), és molt senzill. O se sap tot o no s'apunta res (i es marca el camp 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:
      • Es coneixen els peus de les repeticions, però no a on ocorren (cas dels baixons i clarins). 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.
      • Es coneixen les rengles, però no els peus de cadascuna ni les repeticions (cas més comú dels plens). 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à.
      • Es coneixen les rengles, els peus de cadascuna, però no les repeticions (cas menys comú dels plens). És comú saber que el ple està format per tres rengles que són 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.
      • Cas Dotzena I-II. Per començar, no és un ple i no cal mostrar una composició de ple. Si se sap tota la informació, es mostraria 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.

  4. 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é /.

  5. É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.

  6. 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

  7. 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.

  8. 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.

  9. 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'

  10. 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).

borgue95 commented 4 months ago

Definició de la base de dades amb PostgreSQL (manca la miscel·lània i una data, però per avui ja en tinc prou)

Vegeu-ne el codi ```sql /********************************************************************************************************************** * DOMINIS (tipus amb comprovacions) **********************************************************************************************************************/ -- un o dos números, un o dos números i una fracció o una fracció CREATE DOMAIN peu AS text CONSTRAINT format CHECK (value ~ '^([0-9]{1,2})|([0-9]{1,2} [0-9]\/[0-9])|([0-9]\/[0-9])$'); -- PostgreSQL syntax: per inserir una cometa dins de cometes, s'usa doble cometa CREATE DOMAIN nota AS text CONSTRAINT format CHECK (value ~ '^[a-hA-H]{1}s?['']{0,4}$' ); /********************************************************************************************************************** * TIPUS **********************************************************************************************************************/ CREATE TYPE tessitura AS ( des_de nota, fins_a nota ); CREATE TYPE alçada AS ( nota nota, peus peu[] ); CREATE TYPE transmissió_de_notes AS ENUM ( 'mecànica', 'elèctrica', 'pneumàtica', 'màquina barker' ); CREATE TYPE transmissió_de_registres AS ENUM ( 'mecànica', 'elèctrica', 'pneumàtica' ); CREATE TYPE tipus_extensió AS ENUM ( 'sencer', 'baixos', 'tiples', 'baixos_i_tiples' ); CREATE TYPE actuador AS ENUM ( 'tirador', 'plaqueta', 'lliscant', 'permanent' ); CREATE TYPE família_joc AS ENUM ( 'fons', 'mixtura', 'llengüeta', 'altres' ); /* Una nota a l'hora d'ordenar registres automàticament * 0. Ordre d'alt nivell: fons, mixtura, llengüeta i altres, sempre de més greu a més agut. Se suposa que les mixtures * són jocs amb més d'una rengla des del començament del teclat i que són jocs labials (de fons). És comú, en orgues * antics trobar quinzenes de dues files. Pel nom que se li dóna al registre, considero que és joc de fons i no * una mixtura. Hi ha mixtures de llengüeta, sí, però es tracten com a llengüeta i prou. * 1. Pels jocs de fons i mixtura: principal, flauta, bordó, quintant i gamba. * 2. Un registre amb l'etiqueta 'harmònic' té més pes que un de la mateixa família sense l'etiqueta. * 3. Un registre amb l'etiqueta 'ondulant' té menys pes que un de la mateixa família sense l'etiqueta. * 4. Un registre amb l'etiqueta 'mutació' (que no sona do tocant un do) s'ordenen seguint el criteri 1 * 5. Pels jocs de llengüeta, segueixen aquest ordre: ressonador real, ressonador curt i llengüeta lliure. Entre ells, s'apliquen els criteris 2, 3 i 4 i finalment, l'alçada (primer un clarí i després una veu humana). */ CREATE TYPE subfamília_joc AS ENUM ( 'principal', 'flauta', 'bordó', 'quintant', 'gamba', 'harmònic', 'ondulant', 'mutació', 'ressonador_real', 'ressonador_curt', 'llengüeta_lliure' ); CREATE TYPE actuació AS ENUM( 'nou', 'acabament', 'ampliació', 'reorganització', 'reconstrucció', 'restauració', 'reparació', 'afinació', 're-harmonització', 'trasllat', 'transformació', 'manteniment', 'neteja', 'altres' ); /********************************************************************************************************************** * ORGANITZACIÓ TERRITORIAL (eclesiàstica i política) **********************************************************************************************************************/ /* * Taules Bisbat, Arxiprestat, Municipi, Comarca i Província. Hi són perquè potser ens interessa * emmagatzemar altra informació rellevant per fer classificacions dins la mateixa web. * Per exemple: * - coordenades d'extensió, per centrar la província en un mapa (com les que tinc per Catalunya hard-coded) * - etiqueta o color de l'etiqueta per marcar els orgues * - població per fer estadística d'orgues per càpita (jo què sé...) * - qualsevol altra cosa que puguem menester en un futur */ CREATE TABLE Bisbats ( id integer PRIMARY KEY, nom text, ascii_nom text ); CREATE TABLE Arxiprestat ( id integer PRIMARY KEY, id_bisbat integer, nom text, ascii_nom text, CONSTRAINT id_bisbat_fk FOREIGN KEY (id_bisbat) REFERENCES Bisbats (id) ); CREATE TABLE Província ( id integer PRIMARY KEY, nom text, ascii_nom text ); CREATE TABLE Comarca ( id integer PRIMARY KEY, /* * Ull! * Hi ha comarques que pertanyen a diferents províncies, segons el municipi. Per tant, aquest camp és millor no * coŀlocar-lo aquí. * https://ca.wikipedia.org/wiki/Prov%C3%ADncies_de_Catalunya#Llista_de_comarques_de_cada_prov%C3%ADncia */ nom text, ascii_nom text ); CREATE TABLE Municipi ( id integer PRIMARY KEY, id_comarca integer, id_província integer, nom text, ascii_nom text, CONSTRAINT id_comarca_fk FOREIGN KEY (id_comarca) REFERENCES Comarca (id), CONSTRAINT id_província_fk FOREIGN KEY (id_província) REFERENCES Província (id) ); /********************************************************************************************************************** * ORGUES **********************************************************************************************************************/ CREATE TABLE Orgue ( id integer PRIMARY KEY, /* * El bisbat, la comarca i la província queden especificats en l'arxiprestat i en el municipi * Sé del cert (sense exemples concrets) que els municipis i els arxiprestats no delimiten de * la mateixa manera. * Al cap i a la fi, estem tractant dues divisions territorials diferents, per tant, és * necessària la inclusió de dues referències a tals divisions. */ id_arxiprestat integer, id_municipi integer, nom text, ascii_nom text, adreça text, latitud float, longitud float, /* Definició de diapasó: * { * nota: Note (string) * freqüència: float (number) * temperatura: float (number) * id_registre: integer (number) * } * Sovint, es pren el to de l'orgue (diapasó) amb la mitjana d'alguns registres. Si és així, no cal especificar * el registre; o potser especificar el registre que s'acosta més a la mitjana. És bastant irrellevant i no aporta * res més que no siguin formalismes. */ diapasó jsonb default '{}'::jsonb, temperament text, /* Definició d'estat: * {[ * any: integer (number) * nota: integer (number) * detalls: string (string) * ], ...} * La nota segueix les especificacions mencionades en el README. Potser s'haurien de copiar aquí? */ estat jsonb default '{}'::jsonb, composició text, emplaçament text, observacions text, CONSTRAINT id_arxiprestat_fk FOREIGN KEY (id_arxiprestat) REFERENCES Arxiprestat (id), CONSTRAINT id_municipi_fk FOREIGN KEY (id_municipi) REFERENCES Municipi (id) ); CREATE TABLE Teclat ( id integer PRIMARY KEY, id_orgue integer, nom text, número text, -- ordre del teclat (nombres romans) començant per baix de tot posició_cos_sonor text, tipus_secret text, -- enum? TODO buscar els principals tipus de secret /* Definició de Tessitura * Rang de notes. Dues notes separades per un guionet. Les notes, en notació Helmholtz. */ extensió tessitura, transmissió_de_notes transmissió_de_notes, -- majoritàriament, per defecte. Hi poden haver excepcions transmissió_de_registres transmissió_de_registres, -- majoritàriament, per defecte. Hi poden haver excepcions és_pedal bool, CONSTRAINT id_orgue_fk FOREIGN KEY (id_orgue) REFERENCES Orgue (id) ); /* ULL! Guardem registres i mostrem registres, no pas jocs! * A la composició d'un orgue, comptem jocs i no pas registres! */ CREATE TABLE Registre ( id integer PRIMARY KEY, id_teclat integer, nom text, /* Una nota sobre com saber si falten dades i les dades per defecte * És una llista. Cada element de la llista marca un punt d'interès * - 1 sol punt d'interès. Si la tessitura és NULL, s'assumeix la llargada completa del teclat * Si els peus són NULL, FALTEN DADES * - Més d'un element. Si la primera tessitura és NULL, s'assumeix que comença des de l'inici del teclat * Si la _n_ tessitura és NULL, FALTEN DADES (on comença el punt d'interès?) * Si el peu _n_ és NULL, FALTEN DADES * Exemples: * - Baixons i clarins 4' | 8': [{nota:NULL,peus:[4]},{nota:NULL,peus[8]}]. Comença a C però no se sap on parteix * - Dotzena 2 2/3' | 4' + 2 2/3': [{nota:NULL,peus:[2 2/3]},{nota:cs',peus:[4,2 2/3]}]. Comença a C, parteix a cs' * - Címbala III 1/2': [{nota:NULL,peus:[1/2,1/3,1/4],{nota:c,peus:NULL},{nota:cs',peus:NULL}]. Manca la composició del ple, però se sap on talla * * Depenent de si manca o no informació, es mostrarà la disposició del ple (si és un ple) o informació addicional. */ alçada alçada[], tipus_extensió tipus_extensió, actuador actuador, -- Famílies en general. Glossari i ordenació automàtica de registres família família_joc, subfamília subfamília_joc[], és_un_ple bool, -- per decidir si mostrar una disposició d'un ple (no és deduïble mecànicament) -- Especificacions concretes és_harmònic bool, harmònic tessitura, en_batalla bool, batalla tessitura, en_façana bool, façana tessitura, transmissió_de_notes transmissió_de_notes, -- reescriptura del teclat transmissió_de_registres transmissió_de_registres, -- reescriptura del teclat -- Estalvis és_transmissió bool, transmissió_de integer, és_extensió bool, extensió_de integer, té_préstecs bool, presta_de integer, préstec tessitura, -- Circumstàncies extra-organístiques absent bool, absent_comentari text, observacions text, CONSTRAINT id_teclat_fk FOREIGN KEY (id_teclat) REFERENCES Teclat (id), CONSTRAINT transmissió_de_fk FOREIGN KEY (transmissió_de) REFERENCES Registre (id), CONSTRAINT extensió_de_fk FOREIGN KEY (extensió_de) REFERENCES Registre (id), CONSTRAINT presta_de_fk FOREIGN KEY (presta_de) REFERENCES Registre (id) ); CREATE TABLE Acoblament ( id integer PRIMARY KEY, id_teclat_del integer, id_teclat_al integer, nom text, octava_aguda bool, secret_octava_aguda bool, octava_greu bool, transmissió transmissió_de_notes, observacions text, CONSTRAINT id_teclat_del_fk FOREIGN KEY (id_teclat_del) REFERENCES Teclat (id), CONSTRAINT id_teclat_al_fk FOREIGN KEY (id_teclat_al) REFERENCES Teclat (id) ); CREATE TABLE Efecte ( id integer PRIMARY KEY, id_teclat integer, -- teclat al qual pertanyen, si aplica efecte json, -- TODO observacions text, CONSTRAINT id_teclat_fk FOREIGN KEY (id_teclat) REFERENCES Teclat (id) ); CREATE TABLE Orguener ( id integer PRIMARY KEY, nom text, cognoms text, -- per ordenar per cognom empresa text -- de vegades és una empresa, de vegades, un particular ); CREATE TABLE OrguenerEnOrgue ( id integer PRIMARY KEY, id_orgue integer, id_orguener integer, opus text, any text, date text, -- TODO actuació actuació[], detalls text, CONSTRAINT id_orgue_fk FOREIGN KEY (id_orgue) REFERENCES Orgue (id), CONSTRAINT id_orguener_fk FOREIGN KEY (id_orguener) REFERENCES Orguener (id) ); ```
borgue95 commented 4 months ago

Més coses:

borgue95 commented 4 months ago

Més cosetes:

albertms10 commented 4 months ago
  • 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?).

borgue95 commented 4 months ago

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):

20240424_192359

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:

20240424_192924

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.

borgue95 commented 4 months ago

Més cosetes:

albertms10 commented 4 months ago

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"] }
borgue95 commented 4 months ago

Més cosetes:

borgue95 commented 4 months ago

Més cosetes:

Ordre de la miscel·lània:

albertms10 commented 4 months ago

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).

albertms10 commented 4 months ago

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ó.

borgue95 commented 4 months ago

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ó.