LBS(Sammlung) Squeeze

[wintermute]

Michael, bin jetzt auf 1.21 (von 1.18) und nun bekomme ich Resultate. Cool! Schon voll nutzbar.

Freut mich
Die "Suite" geht erst ab 1.19, wie im ersten Post beschrieben, dann lags sicherlich daran.

Was bei mir nicht richtig geht, ist Volume auf einen festen Wert zu setzen. Was für ein Typ sollte dieses KO denn haben?
...
Die Regler sind ja glaub intern zwischen 0-255.

Der Wert liegt zwischen 0 und 100, alles ueber 100 "bleibt" 100.
Wieso das nicht funktioniert, versteh ich allerdings nicht wirklich... wenn du im Client LBS auf E3 ein "mixer volume 25" anlegst, passiert dann was?
Und mit Lautstärker-Regler meinst du was genau? Ein Visu-Element? Nein, leider nicht - ich hab noch immer keine Visu

gruesse :: Michael

[rdeckard]

Michael, bin jetzt auf 1.21 (von 1.18) und nun bekomme ich Resultate. Cool! Schon voll nutzbar.

Was bei mir nicht richtig geht, ist Volume auf einen festen Wert zu setzen. Was für ein Typ sollte dieses KO denn haben?
Wenn ich z.B. in der Visu den Wert auf 19 setze, dann wird die Lautstärke nicht verändert, aber der Ausgang (Volume) hat den Wert 19. Solange, bis es ein Refresh gibt. Dann hat er wieder den alten Wert (der auch so zu hören ist).

Hast du schon mal einen Lautstärke-Regler getestet. Da bei mir der (sinnvolle) Lautstärke-Bereich sehr klein ist (so zwischen 15 und 35), sollte der Regler auch nur diesen Bereich umfassen. (Möchte verhindern, dass man aus Versehen einen zu hohen Wert erreicht)
Die Regler sind ja glaub intern zwischen 0-255.

[wintermute]

Dies dürfte für viele Zwecke besser geeignet sein als der Oszillator.

Stimmt, hier wohl auch.. Danke!

Also wer den Oszi zur Aktualisierung der Abspielposition braucht(e), braucht ihn jetzt nicht mehr - bitte durch den Telegrammgenerator ersetzen

[gaert]

Kleiner Tipp: Seit 1.21 gibt's den "Telegrammgenerator"-LBS: Funktioniert ähnlich wie ein Oszillator, der Ausgang wechselt aber nicht zwischen 1 und 0, sondern bekommt zyklisch immer den gleichen Wert (E1) zugewiesen. Dies dürfte für viele Zwecke besser geeignet sein als der Oszillator.

[wintermute]

Wegen Client kann ich erst am Abend testen. (Wobei ich heute vermutlich nicht viel Zeit habe.)

Keine Eile

Wobei mir noch einfaellt, wegen der Sync Geschichte:
Ich habe selber noch nix damit gemacht, aber in der Theorie waee es natuerlich moeglich, dass Du deswegen keine Ausgabe bekommst - also der LMS nur Daten fuer den Chef der Syncgruppe rausgibt. Das wuerde zwar meinem Verstaendnis widersprechen, ist aber natuerlich trotzdem im Bereich des Moeglichen
Und ja, auch das Syncen laeuft ueber CLI Kommandos - ich werd mal versuchen in naechster Zeit rauszufinden wie genau das funktioniert.

dank & gruss :: Michael

[rdeckard]

Wegen Client kann ich erst am Abend testen. (Wobei ich heute vermutlich nicht viel Zeit habe.)

[wintermute]

Frage: Im Squeeze Command kann man ja die Befehle für den Client definieren. Was passiert, wenn dort Play und Stop beide den Wert 1 haben?

Wer zuerst kommt, mahlt zuerst
Der Command Baustein ist nur so auf die Schnelle zusammengeschustert, vor allem hat er das Problem, dass - wenn die Eingaenge mit KOs belegt sind - beim Edomi Start eine ganze Latte Befehle abfeuert. Ist mir gestern abend aufgefallen, falscher Vergleich von $E[value] (0 anstatt NULL).
Prinzipiell isses aber momentan so (und eigentlihc sollte das auch so bleiben), dass die Eingaenge sowohl als 0 als auch auf 1 reagieren, will sagen:
0 an Stop bedeutet "Play", 1 an Stop bedeutet "Stop"
Ich war mir naemlich nicht ganz sicher wie das gewuenscht ist - weil ja der eine zB Stop/Play/Pause als 0/1/2 verbaut, der naechste dann aber als getrennte 0/1 KOs.
Mir ist das prinzipiell wurscht, ich dachte so waere es am flexibelsten.

Aber wie gesagt: gleichzeitig geht nicht (spaetestens seit Einstein nicht mehr ). Die Befehle werden von Edomi in einer Queue sequentiell uebergeben, also wird in dem beschriebenen Fall alles hintereinander abgefruehstueckt.

Bekommst Du denn mittlerweile Werte vom Client rausgeworfen?

[rdeckard]

Frage: Im Squeeze Command kann man ja die Befehle für den Client definieren. Was passiert, wenn dort Play und Stop beide den Wert 1 haben?
Und könnte man evtl. Eingänge zusammenfassen, welche nie zusammen verwendet würden?
z.B. Play/Stop/Pause oder auch Previous/Next oder Vol+/Vol-
Man wird ja nicht gleichzeitig ein Previous UND Next schicken. Die Unterscheidung könnte man dann mit einer Zahl machen. E3=1 wäre Play, E3=2 für Stop und E3=3 für Pause.
Würde etwas Eingänge sparen und Fehler vermeiden. (Dafür zulasten der Übersichtlichkeit, man muss halt wissen was E3=2 bedeutet)

[wintermute]

Aber immerhin schon ein Erfolgserlebnis! Gute Arbeit

Naja, scheinbar nicht wirklich

Also im Prinzip geht es darum, die Ein-/Ausgaenge des Server Bausteins mit den Aus-/Eingaengen des Clients zu verbinden. Ohne die Befehlsboxen wuerde das dann prinzipiell so aussehen:

koki.png

Was die Ausgaben angeht: evtl etwas abwarten oder mal den Track wechseln. Eigentlich sollte der Baustein aktuelle Infos liefern, aber vllt wird er tatsaechlich nur bei nem refresh wirklich getriggert.
Ist fuer mich etwas schwierig die ganzen Eventualitaeten zu testen, ich freue mich da also auf Mithilfe

Aber nochmal: der Oszi ist nur (und wirklich *nur*) dazu da, die aktuelle Abspielposition auszugeben. Wird die nicht benoetigt, kann man den auch einfach weglassen.

gruesse :: Michael

[rdeckard]

So, hab vorhin auch mal einen ganz kurzen Test versucht. Anhand der obigen Screenshots hat es auf Anhieb geklappt. (Was soll man eigentlich in den Befehlen der beiden Ausgangsboxen eintragen? Habe im Moment einfach das StatusKO und das KommandoKO abgefüllt...obs Sinn macht, weiss ich nicht. Vorallem bei der 2. Ausgangsbox.)

Nur im Oder-Gatter habe ich im Gegensatz zum Beispiel gar keine Werte, obwohl ich sie ja verbunden habe. (Habe ein Radiosender drin)

squeeze1.png

Die status.html vom LMS sieht in diesem Moment so aus:

squeeze2.png

(Die Zeit-Angabe unterhalb der Lautstärke stimmt übrigens nicht und wird auch nicht aktualisiert.)

Interessant noch, dass ich im LBS ja nur die ID (MAC) EINES Players angebe, der LMS aber dann beide Räume (=2 Player) abspielt, da diese ja synchronisiert sind.
Die Frage ist halt, ob man remote die Synchronisierung setzen/trennen kann. Ich dachte aber, ich hätte mal im API entsprechende Befehle gesehen.

Aber immerhin schon ein Erfolgserlebnis! Gute Arbeit

[fisch3009]

Moin Michael,
habe seit gestern deinen Baustein Einsatz und bis jetzt keine Probleme festgestellt.
Ich werde weiter testen, bin aber auf jeden Fall begeistert, dass du das so schnell umsetzen konntest :-)

[wintermute]

Ja, so aehnlich hab ich das jetzt auch gebaut... die ersten Versionen (vermutlich noch mit Fehlern ) sind im Portal zu finden, 19000200-19000202 (Squeeze Server, Squeeze Client, Squeeze Command).
An den Ein-/Ausgängen wird sich im Laufe der Zeit noch einiges tun, neuere Versionen sind dann vermutlich von er "Pinbelegung" her nicht mehr kompatibel, was bedeutet dass im Logikeditor mitunter nachgearbeitet werden muss. Das ist zwar suboptimal, aber ich kann nicht in die Zukunft gucken.. ausserdem ist das alles noch Beta

Zur Funktionsweise:
Zunaechst werden zwei interne KOs benoetigt, ueber die die Einzelkomponenten kommunizieren, ich nenne die mal SqueezeKommandoKO und SqueezeStatusKO.

Es wird eine Instanz des Server Bausteins 19000200 benoetigt, die wird wie folgt "verkabelt"LMSserver.png

(die Eingangsboxen sind jetz nur zur besseren "Lesbarkeit", die koennen natuerlich entfallen wenn die KOs direkt "aufgelegt werden - das Oder-Gatter ist nur fuer mich, damit ich leichter an die aktuellen Werte komme)
Im Prinzip braucht es also nur die IP bzw den Hostnamen des LMS (eventuell noch den CLI Port, wenn der irgendwie verbogen wurde) sowie Credentials (Achtung, das ist nicht getestet, ich habe kein LMS hier welches Authentifizierung benoetigt, wuerde mich also um Rueckmeldungen freuen).
An E10 des 19000200 wird das zentrale KommandoKO gelegt, an A1 (StatusKO) wird das zentrale StatusKO "angeschlossen".
Alles darueber hinaus gehende sollte in der Hilfe des Bausteins erklaert werden.

Fuer jeden Player wird nun ein Client Baustein 19000201 benoetigt, Verkabelung wie folgt:
LMSlocalmedia.png

Squeeze Command (19000202) sowie der Oszi sind optional, schreib ich gleich noch was zu, die Oder-Gatter sind wieder fuer mich und meine Live-Werte). Zwingend erforderlich sind hier:
-Internes StatusKO an E1
-MAC Adresse des betreffenden Players an E2
-A1 mit dem internen KommandoKO verbinden

Das sollte erstmal ausreichen um Status-Information ueber den betreffenden Player an den Ausgaengen vom 19000201 zu erhalten.
Moechte man den Player steuern, so geht das entweder ueber direkte LMS-Kommandos (ohne playerID am Anfang) an E3 des 19000201 (da dann zB einfach ein "power 1" hinschicken) oder ueber den 19000202 Baustein.
Der 19000202 muss (falls er verwendet wird) wie im obigen Bild angeschlossen werden. Es darf keine playerID im 19000202 definiert sein, durch entsprechende Werte an den Eingaengen (siehe Hilfe) kann dann der Player gesteuert werden.

Grundlegende Funktion sollte damit erstmal gegeben sein... ich bitte um zahlreiches Testen

Im uebrigen sind die Track-Eigenschaften (also die Ausgaenge des 19000201) mitunter anders strukturiert als erwartet, besonders wenn remote-Medien abgespielt werden. Im Bild oben wird ein lokales Medium abgespielt, in folgendem Bild ein Radiosender (man beachte Title, currentTitle & remoteTitle, ebenso Time, Duration & Position):
LMSremoteMedia.png

viel Erfolg

gruesse :: Michael

[MatthiasS]

Du verstehst wahrscheinlich unter dem Client-Baustein, was ich mit Befehlsbaustein meine: Eben der Baustein, der eine Wert umsetzt in das passende Kommando wie Volume etc.




Und der Status- Baustein ist der, der aus dem Server-Baustein die Informationen über den betreffenden Player herausfischt:

[wintermute]

Erstmal danke fuer die (zahlreichen) Antworten.
Ich versuche mal auf alles einzugehen und hoffe, ich ueberseh nix

• Momentan ist es so gebaut, dass es fuer jeden Player einen eigenen LBS geben wird. Alle LBS bekommen parallel die (aufbereiteten) Ausgaben des Server-LBS mit, ignorieren die aber wenn ihre MAC nicht drinsteht. Es wird also vermutlich recht einfach umzusetzen sein, dass ein Client LBS auf jede playerID reagieren kann. Mir ist allerdings nicht ganz klar wie man das dann sinnvoll fuer die Visu aufbereiten kann, aber das ist auch erstmal egal - taete mich dennoch interessieren
• Synchronisation hab ich irgendwie voellig verdraengt, hat vermutlich einfach damit zu tun, dass ich das (bisher) selber noch garnicht benutze. Ja, ist defo wichtig.
• Alarme finde ich selber recht praktisch, auch wenn ich die Funktion nicht nutze Ich setze das mal hinten auf die Liste.
• Mit Durchsagen habe ich bisher nur ein wenig rumgespielt, hauptsaechlich um rauszufinden wie sich das mit aktuell abgespielten Playlisten verhaelt. Das war zwar wirklich nur Rumpspielen, aber ich kann schonmal sagen, dass die Ansagen recht zuegig kommen, also so innerhalb von 1-2s vielleicht.
• Von der sleep Funktionalitaet hab ich mal irgendwann gelesen, mehr nicht Kommt auch hinten auf die Liste.
• Ob ein Befehls-LBS gebraucht wird, weiss ich zZ noch nicht. Im Moment ist es so, dass man den Befehl (in "menschlicher" Form) in den Client-LBS drueckt, also zB sowas wie "volume +5" oder "power 0" oder sowas. Der Server-LBS hat aber sowohl Ein- als auch Ausgaenge fuer "Rohdaten", die braucht er, weil die Befehle vom Client-LBS fuer den Server aufbereitet werden. Es spricht also nix dagegen, diese Schnittstelle zu nutzen wenn man "Sonderbefehle" absetzen moechte.
• Ich versuche die Ausgaenge des Client-LBS auf das "sinnvollste" fuer die Visu zu beschraenken, fuer weiterreichende Infos plane ich dann einzelne LBS ein (sowas wie Kuenster-Informationen oder so), das kommt dann aber auch erst spaeter - zunaechst muss ja erstmal das Grundgeruest stehen
• Und ja, sobald der Code aufgeraeumt ist (so wie der jetzt aussieht kann man das keinem zeigen ), lade ich eine erste Version hoch. Mit der wird man dann auch schon rudimentaer arbeiten koennen. Da kann dann jeder gerne fragen wieso, weshalb, warum oder Anregungen einbringen.

dank & gruss :: Michael

[MatthiasS]

Ich bin für getrennte Bausteine pro Player - Client.

Ich stelle üblicherweise parallel dar, was wo läuft. Die Lösung für den HS ist eigentlich nahezu perfekt (Server/Status/Befehls-Baustein), ich denke da könnte/sollte man Anleihe nehmen.


p.S: ich sehe inzwischen ein Revival des LMS-Universums. Es gibt zahlreiche Os und kommerzille Projekte, hochwertige Player auf PI-Basis bereitzustellen.

Siehe max2play, Hifiberry, picoreplayer usw. Dazu die ganzen Pi-DAC-Aufsätze. Das ist ein Zeichen, dass das System lebt.