ANNUNCIO: C-3PO v2.0 disponibile

[marcoc1712]

Ho passato in release la nuova versione di C-3PO, corretta con l'indicazione di "www.audiodigitale.eu" per il downolad di SOX modificato per il DSD.

EDIT: @Simone, nelle istruzioni per la sostituzione di SOX bisognerebbe indicare che l'installazione di LMS sovrascrive SOX o, ancora meglio, studiare un modo per evitarlo.

Da adesso il repository "http://www.marcoc1712.it/downloads/repository.xml" installa la nuova versione.

Con questo si chiude il giro, che francamente pensavo meno meno oneroso, adesso mi dedicherò alla stesura della documentazione, chiunque voglia collaborare è il benvenuto!

Buon divertimento!

[marcoc1712]

Rilasciata la versione 2.0.12, sistema in modo- spero - definitivo la quetsione dei tipi files.

a. crea una copia della tabella generale delle transcodifiche.
b. per tutti i codec di ingresso gestiti SOSTITUISCE integralmente i profili, disabilitando anche quelli generici (player o modello = *).
c. per i player gestiti da C-3PO, sostituisce integralmente i profili con le istruzioni derivanti da C-3PO.
d. per il players NON gestiti da C-3PO crea righe definite per player, corrispondenti e sostitutive di quelle definite genericamente (player o modello = *).

Tutto questo fintanto che C-3PO è attivo, se lo si disabilita, tutto ritorna come era prima.

Per verificarne il corretto funzionamento, lasciando il log ad INFO per C-3PO, in partenza propone l'elenco delle righe di convert.conf esistenti e caricate, quindi per ogni player che si collega ricalcola quelle di specifica competenza, così da rendere evidente cosa ha fatto.

NOTA BENE:

Se non è collegato nessun player, per i formati gestiti da C-3PO non è presente nessuna riga in Tipi files.
Se sono collegati solo player gestiti da C-3PO, sono presenti solo le righe definite da C-3PO.
Se sono collegati ANCHE players non gestiti da C-3PO, compaiono tutte le righe definite nel custom-convert o altrove, ma valgono SOLO per i players non gestiti da C-3PO, sempre e comunque una riga per player.

Se si vogliono gestire player al di fuori di C-3PO è altamente consigliabile farlo specificando le relative righe di conversione direttamente per singolo player, altrimenti risulta realmente difficile raccapezzarsi in tipi file.

Sarebbe importante un test accurato nelle diverse condizioni, è un aspetto delicato ed è facile inserire errori.

Grazie.

[SimoneFil]

Inizio con una segnalazione:

L'opzione "Abilita C-3PO per il player aggiunti" non funziona. Anche se deselezionata per ogni player aggiunto C-3PO è attivo di default.

Poi,
ho seguito su github la serie di modifiche che andrebbero fatte, Paolo ha addirittura proposto una "ristrutturazione generale" del plugin.

Io dico la mia, magari può servire come spunto: ora come ora l'interfaccia è confusionaria, inutilmente complessa e poco user friendly.

Punto per punto:

- Sample rate supportati (PCM) OK
- risoluzioni DSD supportate (rate = 44100*) OK
- Formati supportati in ingresso/Abilita ricerca (cue sheet)/Abilita 'stdIn' (es. Qobuz)/Abilita la conversione di formato/Abilita il ricampionamento Obiettivamente ci sarà mai qualcuno al mondo che selezionerà AIFF e non WAV? No. Suddividere le opzioni in "Formati Lossy" "Formati Lossless" "File DSD"
- Ricampiona: "Sempre", "Mai", "Solo se la frequenza di campionamento non è supportata", "Solo se sample rate < 48 khz"
- Formato in uscita " [ ... ] "
- Re-sample frequency: Menù a tendina: PCM -> 44.1khz,48khz,88.2khz,96khz,176.4khz,192khz ECC ECC; Secondo menù a tendina che rimane grigio tranne quanto in "Formato in uscita" è selezionato "dsf": DSD -> DSD64,DSD128,DSD256 ECC ECC
- Headroom automatico: OK
- Riduzione di guadagno manuale (in dB) OK
- Loudness Ma chi potrà mai usarlo ... via
- Volume canali Son cose che si modificano dall'ampli; togliere.
- Canali invertiti via
- Qualità ok
- Risposta di fase ok
[...] tutto ok
- Usa orologio di precisione Un utente comune che legge una cosa del genere cosa volete che capisca? Via o rendere più chiaro
- Larghezza di banda minima Come sopra
Tutto il resto ok

- FIltro passa basso per DSD Davvero sono necessari 4 step di filtri passabasso di secondo ordine? Per me no.

[UnixMan]

Punto per punto:
[...]
- Formati supportati in ingresso/Abilita ricerca (cue sheet)/Abilita 'stdIn' (es. Qobuz)/Abilita la conversione di formato/Abilita il ricampionamento Obiettivamente ci sarà mai qualcuno al mondo che selezionerà AIFF e non WAV? No. Suddividere le opzioni in "Formati Lossy" "Formati Lossless" "File DSD"

Non sono d'accordo. Semplificare va bene, ma farlo "Apple-style" - togliendo opzioni e limitando la funzionalità - assolutamente NO.

Per quanto possa sembrare superfluo, agli utenti avanzati quella scelta offre la possibilità di gestire diversamente alcuni formati (ad es. con il meccanismo nativo di LMS, via custom-convert.conf). Senza per questo introdurre particolari complicazioni per gli inesperti. Per cui è sacrosanto che ci sia.

Tutt'al più quello che forse non è troppo chiaro (e che volendo si potrebbe tentare di gestire meglio, ma di certo non limitando la funzionalità) è il significato delle opzioni "Abilita ricerca (cue sheet)/Abilita 'stdIn'".

- Ricampiona: "Sempre", "Mai", "Solo se la frequenza di campionamento non è supportata", "Solo se sample rate < 48 khz"

questo è un punto critico... è qui che (forse) c'è da ripensare un po' tutto.

Il fatto è che C3PO è nato seguendo la stessa logica "inversa" di LMS. Che per certi versi non è particolarmente intuitiva né flessibile per ottenere determinati obbiettivi (alquanto diversi da quelli per cui è nato LMS).

LMS ragiona "all'indietro" (dal dispositivo di uscita verso la sorgente), mentre tipicamente l'utente ragiona "in avanti", dal file di partenza al dispositivo di uscita, cioè sulla base delle caratteristiche del materiale di partenza e di cosa vuole ottenere.

Sotto certi punti di vista quindi andrebbe (almeno in parte) ribaltato un po' tutto: fermo restando il meccanismo delle "capacità" del player, anziché utilizzarle per gestire le cose in modo automatico, queste andrebbero utilizzate solo per porre dei limiti alle scelte "dirette" dell'utente.

- Re-sample frequency: Menù a tendina: PCM -> 44.1khz,48khz,88.2khz,96khz,176.4khz,192khz ECC ECC; Secondo menù a tendina che rimane grigio tranne quanto in "Formato in uscita" è selezionato "dsf": DSD -> DSD64,DSD128,DSD256 ECC ECC

IMHO mischiare DSD e PCM crea confusione. Molto meglio separare completamente le due cose, facendo delle "sezioni" di configurazione separate e dedicate per ogni caso diverso. Per "sezioni" intendo qualsiasi cosa permetta di raggruppare e separare visivamente e logicamente le varie cose. A seconda delle possibilità e comodità di implementazione al limite anche nulla (solo un qualche separatore/titolo), fino a voci completamente separate nel menù del player.

A mio avviso (se si vuole rivedere l'interfaccia), per prima cosa è importante delineare una suddivisione logica dei vari gruppi di opzioni, e quindi decidere se/quali possono essere raggruppate e quali invece devono essere separate (ed eventualmente duplicate per "casi" diversi). Un primo abbozzo (per grandi linee), per cominciare:

• impostazione caratteristiche e limiti fisici del player;
• scelta dei formati supportati (ingresso);
• scelta del formato di uscita(*) in funzione del formato di ingresso (o fissa);
• configurazione elaborazioni PCM->PCM;
• configurazione elaborazioni PCM->DSD;
• configurazione elaborazioni DSD->PCM;
• configurazione elaborazioni DSD->DSD;
• configurazione "effetti" comuni (balance, loudness, filtri, eq., ecc);

(*) include la scelta dei s/r desiderati (non necessariamente uguali ai limiti max) in caso di upsampling (idem per downsampling?), le eventuali esclusioni ("bit perfect pass-through") per stream di ingresso con determinate caratteristiche, ecc.

- Loudness Ma chi potrà mai usarlo ... via
- Volume canali Son cose che si modificano dall'ampli; togliere.
- Canali invertiti via

Nonono... non scherziamo! Sono tutte cose comode ed utilissime!

- Usa orologio di precisione Un utente comune che legge una cosa del genere cosa volete che capisca? Via o rendere più chiaro
- Larghezza di banda minima Come sopra
Tutto il resto ok

via!? stai scherzando?! sono alcuni dei "tweak" fondamentali per agire sulla “qualità” del suono!

- FIltro passa basso per DSD Davvero sono necessari 4 step di filtri passabasso di secondo ordine? Per me no.

Gli standard DSD prevedono un filtraggio di ordine superiore al 7°... ma non per caso c'è la possibilità di scegliere. Se vuoi, con quel menù puoi anche mettere solo un singolo primo ordine. Anche questa è una impostazione fondamentale per agire sulla qualità del suono (nel caso di conversione DSD->PCM o upsampling DSD->DSD), per cui all'utente va data la possibilità di fare ciò che meglio crede.

Simone, vediamo di capirci: tu cosa vuoi ottenere? Un player "audiophile" che ti consente di ottimizzare il suono come vuoi tu o l'ennesima app "preconfezionata" che suona come suona, prendere o lasciare?

A me la seconda ipotesi non piace e non interessa neanche un po'...

[marcoc1712]

Non sono d'accordo. Semplificare va bene, ma farlo "Apple-style" - togliendo opzioni e limitando la funzionalità - assolutamente NO.

Per quanto possa sembrare superfluo, agli utenti avanzati quella scelta offre la possibilità di gestire diversamente alcuni formati (ad es. con il meccanismo nativo di LMS, via custom-convert.conf). Senza per questo introdurre particolari complicazioni per gli inesperti. Per cui è sacrosanto che ci sia.

Tutt'al più quello che forse non è troppo chiaro (e che volendo si potrebbe tentare di gestire meglio, ma di certo non limitando la funzionalità) è il significato delle opzioni "Abilita ricerca (cue sheet)/Abilita 'stdIn'".


questo è un punto critico... è qui che (forse) c'è da ripensare un po' tutto.

Il fatto è che C3PO è nato seguendo la stessa logica "inversa" di LMS. Che per certi versi non è particolarmente intuitiva né flessibile per ottenere determinati obbiettivi (alquanto diversi da quelli per cui è nato LMS).

LMS ragiona "all'indietro" (dal dispositivo di uscita verso la sorgente), mentre tipicamente l'utente ragiona "in avanti", dal file di partenza al dispositivo di uscita, cioè sulla base delle caratteristiche del materiale di partenza e di cosa vuole ottenere.

Sotto certi punti di vista quindi andrebbe (almeno in parte) ribaltato un po' tutto: fermo restando il meccanismo delle "capacità" del player, anziché utilizzarle per gestire le cose in modo automatico, queste andrebbero utilizzate solo per porre dei limiti alle scelte "dirette" dell'utente.


IMHO mischiare DSD e PCM crea confusione. Molto meglio separare completamente le due cose, facendo delle "sezioni" di configurazione separate e dedicate per ogni caso diverso. Per "sezioni" intendo qualsiasi cosa permetta di raggruppare e separare visivamente e logicamente le varie cose. A seconda delle possibilità e comodità di implementazione al limite anche nulla (solo un qualche separatore/titolo), fino a voci completamente separate nel menù del player.

A mio avviso (se si vuole rivedere l'interfaccia), per prima cosa è importante delineare una suddivisione logica dei vari gruppi di opzioni, e quindi decidere se/quali possono essere raggruppate e quali invece devono essere separate (ed eventualmente duplicate per "casi" diversi). Un primo abbozzo (per grandi linee), per cominciare:

• impostazione caratteristiche e limiti fisici del player;
• scelta dei formati supportati (ingresso);
• scelta del formato di uscita(*) in funzione del formato di ingresso (o fissa);
• configurazione elaborazioni PCM->PCM;
• configurazione elaborazioni PCM->DSD;
• configurazione elaborazioni DSD->PCM;
• configurazione elaborazioni DSD->DSD;
• configurazione "effetti" comuni (balance, loudness, filtri, eq., ecc);

(*) include la scelta dei s/r desiderati (non necessariamente uguali ai limiti max) in caso di upsampling (idem per downsampling?), le eventuali esclusioni ("bit perfect pass-through") per stream di ingresso con determinate caratteristiche, ecc.



Nonono... non scherziamo! Sono tutte cose comode ed utilissime!


via!? stai scherzando?! sono alcuni dei "tweak" fondamentali per agire sulla “qualità” del suono!


Gli standard DSD prevedono un filtraggio di ordine superiore al 7°... ma non per caso c'è la possibilità di scegliere. Se vuoi, con quel menù puoi anche mettere solo un singolo primo ordine. Anche questa è una impostazione fondamentale per agire sulla qualità del suono (nel caso di conversione DSD->PCM o upsampling DSD->DSD), per cui all'utente va data la possibilità di fare ciò che meglio crede.

Simone, vediamo di capirci: tu cosa vuoi ottenere? Un player "audiophile" che ti consente di ottimizzare il suono come vuoi tu o l'ennesima app "preconfezionata" che suona come suona, prendere o lasciare?

A me la seconda ipotesi non piace e non interessa neanche un po'...

Come volevasi dimostrare...

[marcoc1712]

All'esercizio aggiungete che qualcuno mi chiede di trattare in ingresso TUTTI i formati ammessi in LMS, di aggiungere le ISO per il DSD, l'equalizzatore parametrico e la definizione dei filtri FIRR per il DRC, magari mettendo in coda BRUTEFIRR.

Ah, dimenticavo, e il RAM DISK dove lo mettiamo?

Disegnate un'interfaccia ordinata, completa e facile da usare, usando gli strumenti disponibili, ed io faccio la versione 3.0 di C-3PO, promesso.

p.s.

Fino a qualche tempo fa, mi si diceva che era inutile ed i file di configurazione erano meglio... Io sono allergico ai file di configurazione ed amo le interfacce grafiche ben congeniate, ma il meccanismo dei plugin in LMS è nato per cose semplici, non credo esista un altro plugin con tante opzioni come C-3PO. Sarebbe a mio avviso sbagliato appesantirlo troppo per renderlo la web gui di sox, ma almeno altrettanto sbagliato sarebbe deprivarlo di funzionalità al solo scopo di semplificazione eccessiva.

E' un compromesso, io ho cercato di fare il meglio, di sicuro si può fare di meglio, avendo chiare da subito le opzioni definitive.

[SimoneFil]

Non penso che si stia parlando di cosa voglia io o meno, il mio è un semplice parere da persona che prova a ragionare sia da developer che da end-user. Poi spetta allo sviluppatore del programma (Marco) decidere cosa trarre dai feedback che gli vengono forniti.

Passando al mio punto di vista (non sto a scrivere "IMHO" davanti a ogni frase, lo do per scontato), non mi piacerebbe nè un player preconfezionato da prendere così come è ma nemmeno un software con un front-end da mal di testa, esistono le vie di mezzo che includono sia semplicità d'uso che duttilità; non per forza bisogna rimanere agli estremi.
DOBBIAMO tenere in considerazione che noi ragionamo da persone che sanno programmare e che conosco il funzionamento dei sistemi operativi in maniera tutto sommato approfondita e quindi hanno una forma mentis orientata a questo; ma siamo una minoranza rispetto a quelli che vogliono semplicemente usare LMS in ambito hi-fi!

Prendiamo un esempio palese: piCorePlayer, lo conosci? (Se la risposta è no rimedia, ne vale comunque la pena da quanto è fatto bene). Scrivi l'immagine sulla SD, metti nel raspberry, attacchi corrente ed ethernet, vai nella WebUI, selezioni il tuo DAC e ascolti la musica. Vuoi modificare alcuni parametri? No problem, hai subito a disposizione una interfaccia semplice e pulita dove impostare buffer, ALSA settings, ip specifico del server etc. Sei uno smanettone che vuole spulciare tra le opzioni meno usare di squeezelite e di linux? Premi il tab "advanced" e ti viene fuori il mondo. Questo è un esempio di un front-end pulito, semplice da usare per i principianti; completo pure per i più accaniti pro-user.

La prima volta che ho usato C-3PO è stato mi pare un paio di anni fa; più per curiosità mia che per reale necessità: ero uno user pienamente soddisfatto di daphile; faceva tutto, in maniera comoda ed è uno dei player meglio suonanti in circolazione oltre che essere pure gratis. Appena ho aperto C-3PO sono stato travolto da una schermata di caselle da selezionare
[anche li... perchè fare due righe di caselle per specificare il sample rate supportato quando con un menu a tendina si può indicare direttamente il massimo sample rate supportato dal proprio dac?]

Provo a districarmi tra le varie opzioni:

"Vediamo che è sto non ottimizza small-integers"
*click sul tasto info*
*compare "non ottimizza small-integers*
"mbeh?"

"canali invertiti? a che serve? se mi metto le cuffie al contrario o mi metto ad ascoltare la musica a testa in giù?"

"mm vediamo .. bit-depth in uscita"
*click su info*
*compare PLUGIN_C3PO_OUT_BITDEPTH_DSD-*
"mm boh metto 64bit, più è meglio è"

"ok ora dovrebbe funzionare"
*mando in play e non si sente nulla*
"ah di default i volumi dei canali dx e sx sono a zero ... ma perchè..." -> e qua ci sono impazzito, lo davo per scontato

Ovviamente l'ho messa sul ridere e so benissimo che le descrizione sono messe così perchè sono opzioni da testare ecc, ma sono ottimi esempi per "mettersi dalla parte dell'utilizzatore"; lo scopo principale di una GUI è quello di "esprimersi nel medesimo modo in cui ragiona l'uomo" per poi convertire ciò nel "modo in cui ragiona il software". Se la GUI non riesce a fare questa mediazione vuol dire che si può ancora migliorare.


Dopo ciò ci ho rinunciato, un po' per pigrizia, un po' per demoralizzazione. Se poi ci sono ritornato è stato per necessità: volevo la mia libreria ovunque non solo nel mio impianto hi-fi a casa, quindi ho messo tutta la mia libreria e logitech media server in un container LXC di un mio server OVH così che se volevo uno stream upsamplato al massimo per l'impianto a casa ce l'avevo, se ero in treno col telefono in 4g mi mandava uno stream in mp3 320, se ero in università attaccato al wi-fi mi mandavo i brani in FLAC con livello massimo di compressione, e così via. L'unico modo ovviamente era "sporcarsi le mani" entrando nel mondo di LMS, squeezelite e C-3PO cosa che ho fatto e di cui sono pienamente soddisfatto e che uso come setup stabile in quanto è la migliore scelta per me.

Poi chiaramente se il target del software siamo noi 4 gatti qua su next hardware rimangio tutto; ma se Marco vorrà esporlo più in "grande" (computeraudiophile, diyaudio ecc) un restyling della GUI imho è d'obbligo.

Che non vuol dire necessariamente togliere metà delle opzioni disponibili*, ma semplicemente rendere il frontend del plugin "user-friendly" invece che "software-friendly", e ciò potrebbe avvenire anche solamente "mettendo ordine" facendo come in piCorePlayer senza dover per forza levare nulla. E secondo me porterebbe anche a una riduzione e snellimento del codice (ma è solo un'intuizione).

[*finchè c'è la possibilità di inserire i comandi manualmente nella casella 'Effetti aggiuntivi', di fatto non stai togliendo niente, e rispondendo al riferimento alle politiche Apple ... raramente tolgono funzioni, le rendono meno accessibili che è diverso]

Ovviamente sono i my 2 cents; tutto nell'interesse del miglioramento in quanto a usabilità e funzionabilità di C-3PO; poi Marco ne tragga ciò che ritiene più consono ai suoi obiettivi per questo plugin

I miei suggerimenti sono da intendersi come tali: idee ed ipotesi per eventuali possibili sviluppi... non certo critiche a ciò che hai fatto fino ad ora.

Quoto in toto; è solo una sorta di "brainstorming"

[marcoc1712]

Non penso che si stia parlando di cosa voglia io o meno, il mio è un semplice parere da persona che sa ragionare sia da developer che da end-user. Poi spetta allo sviluppatore del programma (Marco) decidere cosa trarre dai feedback che gli vengono forniti, nè a me, nè a te.

Passando al mio punto di vista (non sto a scrivere "IMHO" davanti a ogni frase, lo do per scontato), non mi piacerebbe nè un player preconfezionato da prendere così come è ma nemmeno un software con un front-end da mal di testa, esistono le vie di mezzo che includono sia semplicità d'uso che duttilità; non per forza bisogna rimanere agli estremi.
DOBBIAMO tenere in considerazione che noi ragionamo da persone che sanno programmare e che conosco il funzionamento dei sistemi operativi in maniera tutto sommato approfondita e quindi hanno una forma mentis orientata a questo; ma siamo una minoranza rispetto a quelli che vogliono semplicemente usare LMS in ambito hi-fi!

Prendiamo un esempio palese: piCorePlayer, lo conosci? (Se la risposta è no rimedia, ne vale comunque la pena da quanto è fatto bene). Scrivi l'immagine sulla SD, metti nel raspberry, attacchi corrente ed ethernet, vai nella WebUI, selezioni il tuo DAC e ascolti la musica. Vuoi modificare alcuni parametri? No problem, hai subito a disposizione una interfaccia semplice e pulita dove impostare buffer, ALSA settings, ip specifico del server etc. Sei uno smanettone che vuole spulciare tra le opzioni meno usare di squeezelite e di linux? Premi il tab "advanced" e ti viene fuori il mondo. Questo è un esempio di un front-end pulito, semplice da usare per i principianti; completo pure per i più accaniti pro-user.

La prima volta che ho usato C-3PO è stato mi pare un paio di anni fa; più per curiosità mia che per reale necessità: ero uno user pienamente soddisfatto di daphile; faceva tutto, in maniera comoda ed è uno dei player meglio suonanti in circolazione oltre che essere pure gratis. Appena ho aperto C-3PO sono stato travolto da una schermata di caselle da selezionare
[anche li... perchè fare due righe di caselle per specificare il sample rate supportato quando con un menu a tendina si può indicare direttamente il massimo sample rate supportato dal proprio dac?]

Provo a districarmi tra le varie opzioni:

"Vediamo che è sto non ottimizza small-integers"
*click sul tasto info*
*compare "non ottimizza small-integers*
"mbeh?"

"canali invertiti? a che serve? se mi metto le cuffie al contrario o mi metto ad ascoltare la musica a testa in giù?"

"mm vediamo .. bit-depth in uscita"
*click su info*
*compare PLUGIN_C3PO_OUT_BITDEPTH_DSD-*
"mm boh metto 64bit, più è meglio è"

"ok ora dovrebbe funzionare"
*mando in play e non si sente nulla*
"ah di default i volumi dei canali dx e sx sono a zero ... ma perchè..." -> e qua ci sono impazzito, lo davo per scontato

Ovviamente l'ho messa sul ridere e so benissimo che le descrizione sono messe così perchè sono opzioni da testare ecc, ma sono ottimi esempi per "mettersi dalla parte dell'utilizzatore"; lo scopo principale di una GUI è quello di "esprimersi nel medesimo modo in cui ragiona l'uomo" per poi convertire ciò nel "modo in cui ragiona il software". Se la GUI non riesce a fare questa mediazione vuol dire che si può ancora migliorare.


Ovviamente dopo quell'esperienza ho disinstallato C-3PO il medesimo giorno senza nemmeno pensarci. Se poi ci sono ritornato è stato per necessità: volevo la mia libreria ovunque non solo nel mio impianto hi-fi a casa, quindi ho messo tutta la mia libreria e logitech media server in un container LXC di un mio server OVH così che se volevo uno stream upsamplato al massimo per l'impianto a casa ce l'avevo, se ero in treno col telefono in 4g mi mandava uno stream in mp3 320, se ero in università attaccato al wi-fi mi mandavo i brani in FLAC con livello massimo di compressione, e così via. L'unico modo ovviamente era "sporcarsi le mani" entrando nel mondo di LMS, squeezelite e C-3PO cosa che ho fatto e di cui sono pienamente soddisfatto e che uso come setup stabile in quanto è la migliore scelta per me.

Poi chiaramente se il target del software siamo noi 4 gatti qua su next hardware rimangio tutto; ma se Marco vorrà esporlo più in "grande" (computeraudiophile, diyaudio ecc) un restyling della GUI imho è d'obbligo.

Che non vuol dire necessariamente togliere metà delle opzioni disponibili*, ma semplicemente rendere il frontend del plugin "user-friendly" invece che "software-friendly", e ciò potrebbe avvenire anche solamente "mettendo ordine" facendo come in piCorePlayer senza dover per forza levare nulla. E secondo me porterebbe anche a una riduzione e snellimento del codice (ma è solo un'intuizione).

[*finchè c'è la possibilità di inserire i comandi manualmente nella casella 'Effetti aggiuntivi', di fatto non stai togliendo niente, e rispondendo al riferimento alle politiche Apple ... raramente tolgono funzioni, le rendono meno accessibili che è diverso]

Ovviamente sono i my 2 cents; tutto nell'interesse del miglioramento in quanto a usabilità e funzionabilità di C-3PO; poi Marco ne tragga ciò che ritiene più consono ai suoi obiettivi per questo plugin


Quoto in toto; è solo una sorta di "brainstorming"

1. A quello serve il debug ed il beta test, se compare "PLUGIN_C3PO_OUT_BITDEPTH_DSD-" significa che ho usato una chiave per una stringa sbagliata e devo correggerla, se me la segnali come buco mi avvantaggi e lo risolvo, altrimenti puoi considerarlo come un errore di disegno dell'interfaccia se ti fa piacere, ma non lo è ...

Stessa cosa per i canali a vol. 0, era un errore poi risolto.

2. Io conosco sia picoplayer che Daphile, MaxToplay, Vortexbox ed altri, TUTTI hanno creato una sovrastruttura su LMS, io NON VOGLIO fare quello, così come non voglio realizzare la web gui di SOX.

Io rimango al 100% dentro a LMS, non ne tocco una virgola, aggiungo solo un plugin, che poi ognuno usa dove e come vuole, ma il cui scopo è di sostituire al meglio l'uso di custom-convert.conf e tipi file, per un ragionevole numero di opzioni 'comuni'.

Di sicuro rispetto all'obiettivo originario per strada ho aggiunto delle cose (DSD in primis) in parte perché utili a me, in parte perché richieste e valutate ragionevoli.

Posso sbagliarmi, ma credo che pur rimanendo perfettibile, l'obiettivo sia ampliamente raggiunto, certo uno deve sapere quello che fa, se gli interessa solo ascoltare spotify e le radio web non può capire C-3PO (e mai capirebbe custom-convert.conf).


3. Perchè fare una serie di CB invece di un menu a tendina? perchè in quel modo puoi abilitare serie non continue di SR, esattamente come puoi fare in Squeezelite, altrimenti ti potresti trovare a non riuscire a gestire correttamente la combinazione dei due settings.

Non serve? forse, ma allora togliamolo in squeezelite. Appena lo togli, ti esce il tipo che ha un dac con il clock che gestisce solo i multipli di 24000Hz...

Il punto NON è disegnare la gui, ma decidere cosa deve fare. Se decidi di dover gestire i 'buchi' come disegni l'elenco dei sample rates?

4. Sarebbe possibile disegnare la WEB UI a livelli, nascondendo le opzioni meno comuni? Certo, ma aspetto che si arrivi ad una versione condivisa, altrimenti passo il mio tempo a mettere e togliere...

Se porti il problema sul disegno, mentre è sul requisito...

[marcoc1712]

quello che forse non è troppo chiaro è il significato delle opzioni "Abilita ricerca (cue sheet)/Abilita 'stdIn'".

Non piace nemmeno a me, accetto consigli, cosa metto?

questo è un punto critico... è qui che (forse) c'è da ripensare un po' tutto.

Può essere, discutetene pure ed arrivate ad una proposta che considereremo eventualmente per la versione 3.0, io però al momento voglio consolidare quanto ho già fatto, quindi considero prioritarie le segnalazioni di bugs da correggere/piccole migliorie da apportare, rispetto a proposte di completo ripensamento.

un passo per volta.

[UnixMan]

Torniamo a questioni più utili e concrete...

Cominciamo dalla questione delle opzioni oscure, "cue sheet"/"stdin":

Non piace nemmeno a me, accetto consigli, cosa metto?

purtroppo non si tratta banalmente una questione di termini. Certo, il fatto che termini come "stdin" e "cue sheet" possano essere sconosciuti ai più è già di per sé un problema. Peggio ancora, anche chi eventualmente ne conosca il significato ben difficilmente riesce ad immaginare cosa possano significare in quel contesto e quindi quali siano le conseguenze di quelle scelte.

Il vero problema è però che, idealmente, quelle opzioni non dovrebbero proprio esserci: la possibilità di "scorrere"/saltare a posizioni diverse all'interno di un brano è qualcosa che l'utente medio si aspetta da qualsiasi player. Difficilmente l'utente medio può immaginare che la cosa pone delle difficoltà tecniche e che in alcuni casi non è proprio possibile. Idem per il supporto ai servizi di streaming: visto che questi in qualche modo sono previsti dal "sistema", perché mai non dovrebbero funzionare? Questo è quello che immagino sarebbe il punto di vista (nonché i dubbi) di un utente medio, che non conosce nulla dei dettagli tecnici che ci sono "sotto".

Il problema in effetti è proprio questo: così come sono, quelle opzioni "portano allo scoperto" ed espongono all'utente dei dettagli tecnico-implementativi del sistema che lui non ha (non dovrebbe avere) alcun bisogno di conoscere (non sono di sua competenza) e di cui, con ogni probabilità, è completamente all'oscuro. Per cui ovviamente ed inevitabilmente si trova in difficoltà di fronte a quelle opzioni.

Quale potrebbe essere, allora, la soluzione?

Idealmente (se è tecnicamente fattibile, e questo non lo so), la cosa andrebbe gestita in modo dinamico ed automatico da C3PO, caso per caso, in funzione dello stream che deve essere riprodotto in quel momento:
il "seek" all'interno dei brani dovrebbe sempre essere abilitato se/quando ciò sia possibile, salvo disabilitarlo automaticamente quando ciò si renda necessario (per poi riabilitarlo non appena sia di nuovo possibile farlo). Idem per la possibilità di utilizzare qualsiasi servizio di streaming. Il tutto senza richiedere nessun intervento né alcuna configurazione da parte dell'utente.

Qualora ciò non fosse tecnicamente realizzabile (quanto meno non senza improponibili modifiche ad LMS) l'opzione andrebbe ripensata, presentando all'utente un quesito che riguardi non già ciò che accade a livello tecnico, ma piuttosto gli effetti che ne conseguono, il risultato che se ne ottiene.

In altre parole, ad es. la scelta potrebbe essere fatta banalmente con una sola coppia di "radio button" che pone una semplice alternativa, immediatamente comprensibile da chiunque:

(o) "abilita la ricerca all'interno dei brani"
( ) "supporta i servizi di streaming X/Y/Z"

(magari spiegando brevemente nelle info relative che purtroppo non è possibile avere entrambe le cose, e quindi è necessario scegliere a cosa rinunciare).

IMHO eviterei inoltre di ripetere tale opzione per ciascun formato, cosa che risulta prolissa e dispersiva: al più, come suggerito da Simone, potresti semplicemente offrire l'opzione separatamente per i tre diversi "gruppi" di formati:

PCM lossy
PCM lossless
DSD

(al limite, per permetterti di continuare a usare il workaround che usi tu, potresti aggiungere un ulteriore gruppo "PCM non compresso")

IMHO comunque anche una scelta unica, valida per tutti i formati, basta e avanza... e sicuramente rende tutto più semplice, ordinato e comprensibile "ai non addetti". Oltre tutto, con una scelta unica diventa semplice e veloce agire manualmente per cambiare da una modalità all'altra ogni qual volta che ce ne sia bisogno. Cosa che forse è più utile e pratica di altre soluzioni parziali più complesse da gestire (e non sempre applicabili).

Valuterei inoltre se sia utile configurare la cosa separatamente per ciascun player o se al contrario tanto vale assumerla come opzione comune per tutti i player, e quindi spostarla nella sezione globale (anche in questo caso, una unica opzione globale semplificherebbe la gestione manuale di volta in volta).

Per quanto riguarda poi la selezione dei formati supportati in ingresso, non riesco a vedere l'utilità di duplicare la scelta anche nella sezione "per player" (per altro al momento -v2.00.15- vedo che non c'è nulla di modificabile... perché non rimuoverla del tutto, lasciandola solo tra le impostazioni globali? IMHO così com'è genera solo confusione).

Anche le scelte "enable transcoding" ed "enable resampling" le limiterei ai tre/quattro gruppi di cui sopra piuttosto che ai singoli formati.

Un'altra possibilità (da valutare) potrebbe essere quella di raggruppare tali opzioni con qualcosa del genere:

formati di ingresso:   abilita  transcoding resampling streaming(*)
--------------------   -------  ----------- ---------- ---------
PCM lossy                 y          y           n         y      
PCM lossless              y          y           y         n
PCM raw                   y          y           y         n
DSD                       y          y           n         n

(*) abilitando i servizi di streaming si abilita la modalità sequenziale e si perde la possibilità di saltare a posizioni diverse dall'inizio all'interno di un brano

Per quanto riguarda invece la selezione dei sample rate, di cui si lamentava Simone, in effetti il problema è che finché le righe vengono mostrate per intero va tutto bene ma, non appena il browser comincia a spezzarle andando a capo di "testa sua" (in funzione della risoluzione e delle dimensioni del monitor, di quelle della finestra del browser, dello zoom, ecc.), la soluzione attualmente adottata può apparire estremamente prolissa, disordinata e confusa.

La soluzione che propongo è la seguente:

PCM11 [x] Min: (menù: 11025, 22050, ... , 705600) - Max: (menù: 44100, 88200, ... , 705600)
PCM12 [x] Min: (menù: 12000, 24000, ... , 768000) - Max: (menù: 48000, 96000, ... , 768000)
DSD11 [x] Max: (menù: 64x, 128x, ... , 1024x)
DSD12 [ ] Max: (menù: 64x, 128x, ... , 1024x)

ne dovrebbe risultare una presentazione più chiara, ordinata e leggibile in (quasi) tutti i casi.

Rispetto alla soluzione attuale si perde (solo) la possibilità di creare "buchi" all'interno di una serie, ma è una eventualità di cui non vedo alcuna utilità pratica: non mi risulta esista alcuna scheda/DAC/interfaccia USB che abbia limitazioni/necessità del genere. Tutte le combinazioni di cui si può avere necessità in pratica sono coperte.