Ne wird keine Live-Kachel - dafür müsstest du es wirklich als Metro-App umbauen - und nemp würde ich momentan doch nicht als Touchfähig erachten xD

Btw: Wenn ich mir das hier dazu ansehe, scheinen die ja echt einige Audio-Playback-Features in Win8 implementiert zu haben .

Kam ja schon gestern in der SB - da hat jemand einen neuen Skin für Nemp gebastelt, den ich sehr überzeugend finde, und den ich auch gerne als Default in der nächsten Version mitliefern würde. Jetzt kam die nächste Mail mit einem neuen Logo / Splashscreen. Und da das dann eine doch recht krasse Änderung des Looks bzw. der "Marke" Nemp wäre, würde ich gerne ein kleines Stimmungsbild abholen. Mir persönlich gefällt das sehr gut, da der aktuelle Look doch etwas sehr hausbacken rüberkommt.

Damit der Thread nicht unnötig lang wird () würde ich ein "Danke" auf dieses Posting als "Jo, gefällt mir, weg mit dem alten" interpretieren und ein "Danke" auf folgende Postings als Zustimmung zu der dort vertretenen Meinung.

Fein - da das Feedback hier ja wie gewollt war, und die Scrollbars auch noch *mist*e aussahen, hab ich mir mal XE3 besorgt und ein bissel was rumprobiert (mit Hilfe).

Ich hab zwar jetzt ne kaputte Playlist (wohl irgendein Drag&Drop-Problem im VST), aber dafür siehts jetzt schön aus. Ein paar Sachen müssen noch angepasst werden (z.B. Sternchen im Detail-Dialog, [x] bei der Schnellsuche) und der Code muss an einigen Stellen auch erweitert werden (VCL-Style an/aus), aber sonst gefällt mir das.

Jau, jetzt sieht es aus wie aus einem Guss.

Kleiner Verbesserungsvorschlag: Tausch mal bei der Schnellsuche das rote Icon gegen ein graues x aus. Das Icon sticht jetzt doch etwas sehr in die Augen .

hallo gausi...
das halte ich doch mal für gelungen, ein skin wie man es sich wünsch!
SUPER !!!!!

TDP (Jürgen)

Moderiert von Gausi: Beiträge zusammengefasst

...übrigens, den Skin-Editor habe ich angefangen,
studiere gerade dein skin-system u. überlege wie das UI aussehen soll, kann
also noch dauern bis die erste beta fertig ist...


bis dann TDP (Jürgen)

in der Entwickler-Ecke.

Naja, das weitere kommt ja nicht von mir. Bei XE3 sind ein paar VCL-Skins mitgeliefert (die auch weiterverbreitet werden dürfen), und einer davon (Carbon) passt recht gut zu dem, was du mir da geliefert hast. Bei Facebook kommt das übrigens auch gut an, und zwar weltweit. Positives Feedback bisher aus Deutschland, Norwegen (Schweden? Finnland?), Indonesien und Brasilien. Von einer Viralität von >20% können andere Fanseiten nur träumen. Ich bin berühmt.

Skinsystem muss übrigens erweitert werden - da kommt noch so eine vsf-Datei für den VCL-Style dazu, und ein Eintrag in der Ini, falls das genutzt werden soll: [Options] UseAdvancedSkin=1

Portierung auf XE3 ging übrigens relativ problemlos, und nachdem ich gelernt habe, dass ein Ändern des Skins jetzt das Fensterhandle ändert, krieg ich die ganzen Threads auch wieder zum laufen. Und wie es scheint, werden die Fehler "Ungültiges Fesnterhandle" langsam weniger.

...schieb mir mal den source rüber, meine mailadresse hast du ja, erspart mir arbeit...
oh es freut mich sehr, dass das logo u. der skin so gut ankommt !

TDP

...habe den Fehler in der Display-Darstellung behoben.

Ich fürchte, der ist da nicht behoben, sondern nur besser versteckt. Schau mal genau hin, der Farbverlauf im Player ist da nicht ganz sauber. Der Fehler liegt sehr wahrscheinlich im Code. Aus der Player-Grafik schneide ich nämlich einen Teil aus und nutze den als Hintergrund für die Spektrum-Grafik. Beim Kopieren ist das Offset sehr wahrscheinlich nicht ganz richtig - da muss ich nochmal genauer drübergucken.

Da verschluckt sich Nemp an den Umlauten:

Oder wird das nicht richtig übertragen?

Das stammt aus diesem Webradiostream:
starfm.de/streams/fh_m.pls

klick

Dürfte ein UTF8-Problem sein, schau ich mir mal an.

Edit: Einige Streams senden Metadaten in UTF8, andere Ansi. Eine automatische Erkennung (außer über Heuristiken) scheint nicht möglich zu sein. Denkbar wäre höchstens, das für jeden Stream in der Verwaltung einzustellen, das wird aber nichts in der nächsten Version.

Ich hab gerade noch einen Käfer gefunden und zwar im "Keyboard Display". Ich hatte eine Playlist offen, die nach der Reihe abgespielt wurde. Dann habe ich ein anderes Lied gesucht und dieses abgespielt aber ohne die Playlist zu verändern (also nach dem Stück dann weiter in der Playlist).

In dieser Konstellation wird im Display aber das falsche Stück angezeigt - nämlich das, was zuvor abgespielt wurde - und der Zeitbalken passt dann folglicherweise auch nicht mehr.

Das liegt an der dreckigen Tastatur, da kommen die Daten nicht richtig an.

Schau ich mir aber an - da liefert die API wohl was falsches zurück.

//Edit: Hm, da muss ich mir wohl doch die Keyboard-App (und das Deskband) vornehmen. Aktuell läuft das so, dass für die Abfrage des aktuellen Titels sein Index in der Playlist abgefragt wird, und dann die Daten über den Index abgerufen werden. Dieser Index muss ja aber gar nicht existieren, wenn der Titel gelöscht wurde, aber noch abgespielt wird.

Ich bin nun auch stolzer Besitzer einer G510. Funktioniert gut!
Einen Vorschlag hätte ich: Wenn man Internetradio hört und auf Pause drückt, erscheint "(stopped)" im Display. Wenn man dann auf Play drückt, dauert es einen Moment, bis die Musik wieder spielt, weil sich Nemp erst wieder mit dem Stream verbinden muss. So scheint es im ersten Moment so, als würde Nemp auf den Tastendruck nicht reagieren. Vielleicht könnte man in dem Fall nach Druck auf Play den Text "stopped" durch "connecting" ersetzen. So sieht man, dass was passiert.

Hallo Gausi

Kann es sein, dass NEMP eine Liedberanzahlbegrenzung hat oder mit einer gewissen Anzahl nicht umgehen kann?
Wenn ich meine Platte indexieren lassen möchte, stürzt mir NEMP jeweils ab, ich kan nicht einmal mehr die Fehlerlog oder ähnliches speichern. Meldung: Zuwenig Arbeitsspeicher, wenn ich diesen beim Indexieren jedoch überwache, habe ich immer noch mehr als genug übrig.

Grüsse

Stübi

Das sollte eigentlich nicht passieren. Allerdings bist du schon der zweite, der mit dieser Meldung ankommt. Ein anderer hat da Probleme beim Update von 4.2 auf die aktuelle Version.

Ich teste mit ca. 50.000 Files und habe keine Probleme.

An dem "FileList.Add(newAudioFileObject)" dürfte es eigentlich nicht liegen - da gehen höchstens ein paar MB "verloren", wenn die Listen-Kapazität schrittweise um 25% erhöht wird (das passiert da ja intern).

Wenn der Fehler kurz vor Ende des Vorgangs kommt: Eventuell liegt es an den Suchoptionen - stell da mal bitte die Beschleunigung aus.... mir kommt da grade ein böser Verdacht.

Ist leider wieder passiert
Ich kann den Bugreport weder speichern noch senden
Habe kurz zwei Printscreens gemacht. Sag mir welche Infos Dir eventuell helfen würden.
Die Beschleunigung habe ich in den Optionen ausgeschaltet Gefühlsmässig gings etwas länger gut aber das ist nur ein Gefühl

Grüsse

Stübi

1.8GB ist für einen 32Bit-Prozess schon viel. Wenn, dann hilft aber höchstens der call stack weiter, um rauszufinden, an welcher Stelle es knallt.

Eigentlich kenn ich die Fehlermeldung nur, wenn ein Bitmap zu groß wird. Das kann auch gerne mal lange vor dem Ende des Speichers passieren...

Ist da irgendwo eine Datei mit absurd großem Cover?

Übrigens könnte der Bugreport auch stillschweigend in deinem Clipboard landen, madExcept macht das bei mir immer so.