BASS-Library

Status
Für weitere Antworten geschlossen.

USM69

Benutzer
Weiß jemand was mit der Website von Un4Seen los ist? Keine Seite der Domain ist erreichbar. Ein Ping schafft nur einen Schritt, zur IP 64.20.43.147 mit anschließender Zeitüberschreitung. Eine Whois-Abfrage brachte mich auch nicht weiter: Expiration date: 01 Nov 2014 14:16:08. Auch unter http://www.un4seen.co.uk/ passiert nichts.

Wem Un4Seen nichts sagt: Das sind die Entwickler der BASS-Library, eine Bibliothek u.a. zum Abspielen von MP3 unter Windows, die von diverser Software wie z.B. mAirList verwendet wird. Daher habe ich mich mit meiner Frage auch für die Kategorie Studio- und Sendetechnik entschieden.
 
AW: BASS-Library

Wie funktioniert die datenbank denn generell?
hab da keine ahnung von und nach einem ersten blick ins beiliegende manual isses mir auch nich verständlicher geworden.

vielleicht kannste mir da ne hilfestellung geben, usm69?

gruß Hulle
 
AW: BASS-Library

Wie funktioniert die datenbank denn generell?
vielleicht kannste mir da ne hilfestellung geben, usm69?

Was denn für eine Datenbank? :confused: Sorry, aber ich verstehe nur Bahnhof.

Flugsaurier schrieb:
Sie funktioniert wieder zumindest als ich gerade drauf war!

Verschiedene Browser ausprobiert, Router ersetzt, Firewall deaktiviert, Antivirensoftware deinstalliert, DSL-Modem ausgetauscht und PC aus dem Fenster geworfen. Na gut, war ein wenig übertrieben, aber die Seite ist für mich nicht aufrufbar. Selbst der Google-Cache konnte am 8. Dezember 2007 um 14:26:56 (GMT) nur einen leeren Schnappschuss ablegen. Sehr merkwürdig. :(
 
AW: BASS-Library

Dein in #1 angegebener link funzt auch bei mir. Mein Cache war vorher leer.

Versuch' mal, den Rechner aus 'nem höheren Stockwerk zu werfen.

Gruß, Uli ;)
 
AW: BASS-Library

also: usm69, du meintest doch das die bass libary ne bibliothek für mp3`s wäre.. ... demtetsprechend hab ich draus gefolgert, dass man in diese libary seine mp3 datein einarbeiten und die über eine sendeautomation (--> mairlist) komfortabel abrufen kann. demzufolge hab ich sie mit "datenbank" gleichgesetzt (ala eldoDB (für mairlist eben))versteh ich das bis jetz richtig?
nun, sowas will ich auch, deswegen habe ich mich dazu entschlossen, die bass libary zu saugen und benutzen zu wollen. ich versteh die nur nich. also wie das geht versteh ich nich.

und deswegen hatte ich um hilfe angefragt. hoffe jetz is einiges klarer.
 
AW: BASS-Library

@ Hulle: Auf der mAirList-Seite und in dem dortigen Forum (resp. wiki) warst Du schon?
Dann nämlich würde Dir schlagartig klar, warum Deine Frage ein wenig absurd erscheint.

mAirList benutzt die bass.dll zum Abspielen der mp1/2/3 / wav / ogg - Dateien.
Mit den RadioDB, eldoDB und sonstigen Datenbanken (selbst iTunes) hat das nichts zu tun.

Alle Klarheiten beseitigt?
Gruß, Uli
 
AW: BASS-Library

ja, hab schon ins wiki geguckt, und auch das forum da besucht.
aus welchem grund lade ich mir denn die bass libary runter? was kann die, was macht die anders als wie die die wo bei mairlist dabei ist?

ja, und das mit den datenbanken hab ich auch gelesen. eldo DB und co. gibts da irgendwo nen genaues tutorial wie man sowas einrichtet? hab so gar keinen plan.
foren suche im mairlist forum hab ich auch schon bemüht aber irgendwie nichts gefunden.. .... hoffentlich bin ich nich blind und seh die wiesevor lauter gras nich.

lieben gruß
 
AW: BASS-Library

Bei mAirList ist exakt die gleiche BASS.DLL dabei, die du dort herunterladen kannst. Oder genauer: Diejenige Version der BASS.DLL, die keinen eingebauten MP3-Decoder hat, sondern stattdessen den von DirectX nutzt. Die findest du im BASS-Zip-Archiv unter "mp3-free".

Die BASS.DLL ist nur für Leute interessant, die selbst Abspielsoftware programmieren möchten (USM69? Willst du Torben Konkurrenz machen? *g*). Als normaler, nicht-programmierender User kann man mit der DLL selbst wenig anfangen.

Allerdings kann man auf der un4seen-Seite einige Plugins herunterladen, mit denen man mAirList weitere Dateiformate beibringen kann, zum Beispiel WMA oder AAC.

Für Fragen zur Einrichtung von Datenbanken gibt es auf der mAirList-Seite ein eigenes Unterforum. Dort findest du, was du suchst.
 
AW: BASS-Library

Versuch' mal, den Rechner aus 'nem höheren Stockwerk zu werfen.

Hat auch nicht gebracht, außer dass ich mir nun einen neuen kaufen müsste und die Nachbarn sauer sind. Hätte ich auch nicht unbedingt mitten in der Nacht entsorgen müssen. :D

Ein netter Kollege aus Hamburg kannte einen Trick, den er mir mitteilte. Über eine mir bisher nicht bekannte Subdomain der Un4Seen-Website konnte ich mir die Dateien herunterladen. Recht herzlichen Dank für den Tipp!

Da außer mir wohl jeder auf die Un4Seen-Seiten zugreifen kann werde ich mich mal an meinen Internetanbieter wenden. Eigentlich kann es ja nur noch dort haken.

Hulle schrieb:
seh die wiesevor lauter gras nich.

Wie Studio Rebstock bereits schrieb: Auf den mAirList-Seiten wirst du Antworten auf deine Fragen finden. Gerne helfe ich ein paar Leuten, aber ich kann nicht jedem behilflich sein. Ich hoffe, du kannst dies verstehen. Zudem arbeite (teste) ich nur sporadisch mit mAirList und ohne Datenbank-Anbindung.

yps77 schrieb:
Die BASS.DLL ist nur für Leute interessant, die selbst Abspielsoftware programmieren möchten

Nein, Torben wird durch mich keinen Mitbewerber erhalten. Mein Vorhaben geht eher in Richtung Musikverwaltung, die ein vorhören ermöglichen soll, aber das eigentliche Abspielen dann doch besser anderen Programmen überlassen sollte.

Vielen Dank für die bisherigen Beiträge zu diesem OT-Problem.
 
BASS.dll 2.4 bringt Error in mAirList

Hallo liebe Community!!

Ich verfolge schon länger die Beiträge hier im Forum und brauche nun selber Hilfe.
Ich verwende mAirList und wollte das Add-On für die Wiedergabe von AAC-Files installieren. Würde ja soweit funktionieren, wenn ich nicht dazu die neue BASS.dll Version 2.4 brauchen würde. Aber mit dieser Version geht mAirList gar nicht mehr. Bei jedem File - egal ob wav, mp3, aac etc bringt er mir eine Error-Meldung.
Ich weiß nicht, was ich machen muss, damit das mit der Version auch geht. Vielleicht geht es ja gar nicht und ich kann da versuchen, was ich will.
Ich würde ja gern die AAC-dll in der Version 2.3 testen, aber ich finde diese nicht im Internet zum runterladen.

Vielleicht wisst ihr einen Rat oder wisst, wo ich die ältere dll-Datei downloaden kann.

Mit besten Grüßen und dank schonmal für eure Hilfe,
Christian
 
AW: BASS-Library

Hallo Christian,

was hast Du denn im mAirList-Forum für eine Antwort auf Deine doch sehr spezialisierte Frage hinsichtlich des Programms bekommen?

Ich denke mal, Torben ist im dortigen Forum viel näher an der Sache dran als wir hier.... ich verbeuge mich in Demut vor dem Programmierer... :cool:
Journalistische Weisheit: Warum Sekundärquellen nutzen, wenn die Primärquelle problemlos erreichbar ist?

Gruß, Uli ;)
 
AW: BASS-Library

Also, ich habe im mAirList-Forum nachgefragt und folgende Antwort bekommen:

mAirList 2.x ist nicht mit BASS 2.4 kompatibel. Du musst weiterhin BASS 2.3 und seine Plugins verwenden. Im Zweifel mal beim Autor der Plugins oder hier im Forum nachfragen, ob man dir eine alte Version zusenden kann.

mAirList 3.x wird dann mit BASS 2.4 arbeiten.

Leider hat sich bei BASS 2.3 und BASS 2.4 ziemlich viel an der API geändert, so dass sich die arbeitsaufwändige Anpassung von mAirList 2.1 nicht mehr lohnt.

Ist schön und gut und ich habe kein Problem damit, dass ich die Bass.dll 2.3 brauche. Jedoch finde ich keine AAC.dll in der Version 2.3 mehr im Internet. Hat vielleicht jemand von euch diese dll auf seinem PC und würde sie mir per Mail schicken?? Das wäre nett.


Beste Grüße,
Christian
 
AW: BASS-Library

[OT]
Das ist das, was ich an solchen Projekten hasse. API-Änderungen gehen *gar* nicht und wenn, dann nur mit langer Vorankündigung, um allen, die die API verwenden, Gelegenheit zu geben, auf die neue umzusteigen. Was, in Dreiteufels Namen, spricht denn dagegen, die alten Library Calls noch ein, zwei Versionen drin zu lassen, die eigentliche Arbeit dann auf die neuen Routinen schon umzulenken, die alten Calls "deprecated" zu markieren und EOL für die in Version X in der Zukunft anzukündigen?

Ich mein, ich find's ja toll, daß es so viele freie Projekte da draußen gibt, aber es sollte doch - gerade Entwicklern von Libraries - bewußt sein, daß möglicherweise andere Leute Software auf Grundlage des eigenen Projektes entwickeln, denen man mit solchen Stunts gehörig Knüppel zwischen die Beine wirft... So schwer ist doch das alles nicht *seufz*

Naja, genug gewettert, zurück zum Thema.

LG

McCavity
[/OT]
 
AW: BASS-Library

Wo ist denn das Problem? Hier hat ein Nutzer einer "Endbenutzer-Software" - ohne vorher deren Entwickler zu konsultieren - eine neue Version einer Library installiert, die er eigenständig aufgespürt und heruntergeladen hat. Dass die Library nicht zu der vorhandenen .exe passt, weil sich APIs geändert haben, ist nichts Außergewöhnliches. Da trifft den BASS-Entwickler keine Schuld. Im Gegenteil, der arbeitet äußerst vorbildlich, was das Dokumentieren neuer und geänderter Features angeht. Nur muss natürlich erstmal der Entwickler der "End-Software" sein Programm auf die neue API umstellen. Da haben aber die Endbenutzer nichts mit zu tun, solange sie weiterhin die mitgelieferten Libraries verwenden und nicht auf eigene Faust Updates machen.

Der einzige berechtigte Kritikpunkt ist hier tatsächlich, dass die alten Plugins nicht mehr zum Download angeboten werden. Hier sollte sich der BASS-Entwickler schnell eine Lösung einfallen lassen, und sei es nur, die Dateien irgendwo dauerhaft in seinem Download-Verzeichnis zu archivieren.

In der Frage ist dann aber das BASS-Forum die geeignete Stelle um nachzufragen: http://www.un4seen.com/forum/?board=1.0
 
AW: BASS-Library

[OT]
Das ist das, was ich an solchen Projekten hasse. API-Änderungen gehen *gar* nicht und wenn, dann nur mit langer Vorankündigung, um allen, die die API verwenden, Gelegenheit zu geben, auf die neue umzusteigen.

Und genau deshalb murkst Intel immer noch mit der alten 8080-Architektur rum nur um mit aller Gewalt abwärtskompatibel zu sein. Dass dadurch 30-50% Geschwindigkeit verloren geht, spielt wohl keine Rolle.

Ich sehe das Problem nicht, wenn sich eine API ändert. Immerhin hat es ja in den meisten Fällen den Sinn, schneller/besser/schöner zu werden. Und solange das Programm mit der alten API geliefert wird, ist es ja OutOfTheBox lauffähig. Wer nun meint, ohne irgendwo nachzulesen, eine neue Version einspielen zu müssen, ist selber schuld.

Oder beschwertst du dich auch bei BMW, dass der Motor aus nem alten 02er in nen E46 nicht mehr reinpasst, nur weil die so nen überflüssigen Kram wie elektronische Einspritzung o.ä. einbauen und sogar, unverschämter Weise, die Motoraufhängung geändert haben, ja noch schlimmer, den kompletten Motor neu entwickelt?
 
AW: BASS-Library

Wo ist denn das Problem? Hier hat ein Nutzer einer "Endbenutzer-Software" - ohne vorher deren Entwickler zu konsultieren - eine neue Version einer Library installiert, die er eigenständig aufgespürt und heruntergeladen hat. Dass die Library nicht zu der vorhandenen .exe passt, weil sich APIs geändert haben, ist nichts Außergewöhnliches. Da trifft den BASS-Entwickler keine Schuld. Im Gegenteil, der arbeitet äußerst vorbildlich, was das Dokumentieren neuer und geänderter Features angeht. Nur muss natürlich erstmal der Entwickler der "End-Software" sein Programm auf die neue API umstellen. Da haben aber die Endbenutzer nichts mit zu tun, solange sie weiterhin die mitgelieferten Libraries verwenden und nicht auf eigene Faust Updates machen.
Jein. Ich sage *nichts* dagegen, daß sich eine API ändert - das ist notwenig und sinnvoll. Und Pegasus, ich spreche auch nicht dafür (steht sogar explizit drin), jeden API-Call von anno Dunnemals bis zum St. Nimmerleinstag in der Library zu belassen. Wenn ein *Endbenutzer* ein Produkt mit einer inkomptatiblen API-Version zu betreiben versucht, ist das in der tat sein Problem. Aber davon habe ich auch gar nicht geredet.

Ich rede davon, daß hier offensichtlich von Version 2.3 zu Version 2.4 der Library so viel geändert hat, daß eine Umstellung der Software notwendig wird, um die neue Library verwenden zu können. Zum Einen hätte ich es besser gefunden, wenn der Entwickler das durch einen großen Versionssprung kenntlich gemacht hätte (also direkt auf 3.0) und (falls nötig) die alte Version mit weiteren 2er Updates. Aber gut, ist sein Nummerierungssystem, ich finde nur, solche Sprünge rechtfertigen eine Große Versionsnummer, selbst dann, wenn nicht auch neue Features mit drin sind.

Zum zweiten reißt er dadurch, daß die alten Calls komplett aus der API verschwunden sind, allen Entwicklern, die darauf aufbauen, den Teppich unter den Füßen weg. *jeder*, der die neue Version nutzen will, *muß* seine Software umschreiben. Diese Friß- oder Stirb-Methode mag ja durchaus verbreitet sein und sicherlich auch sinnvoll, alte Zöpfe wegzuschneiden - aber dadurch könnte er im Zweifel auch Projekte gefährden, je nachdem, wie groß der Aufwand ist, die neue API zu lernen und die darauf aufsetzende Software neu zu entwickeln.

Meinen Lösungsansatz dazu hatte ich ja schon beschrieben: Alte Calls (und Returnwerte) ändern sich zunächst einmal *nicht* sie werden aber ab sofort in der Dokumentation als "deprecated" geführt. Wenn möglich, baut man entweder die neue Funktionalität durch Calls auf die alte API auf (und macht diese dann später irgendwann mal nicht mehr direkt aufrufbar), oder man leitet die alten Calls für eine Weile auf die neuen einfach um, bevor man sie dann in einer zukünftigen Version endgültig löscht, oder, wenn das beides nicht funktioniert, existieren halt für eine Weile alte und neue Version nebeneinander, bis dann die alte irgendwann rausgelöscht wird. Wichtig halt nur, daß alte und neue Calls für eine Karenzzeit parallel existieren.

Der Grundsatz sollte hier meiner Ansicht nach lauten: Interface nur langsam und mit ausreichend Vorwarnung ändern, Implementation kann man jederzeit ändern. Dadurch erlaubt man auch Programmierern, die nicht gleich Gelegenheit haben, ihre Software anzupassen, die neue Library schon zu benutzen. Nach einer Karenzzeit (Vielleicht ein oder zwei Jahre) fliegt dann endgültig alles raus, was zuvor "deprecated" markiert wurde. Diesen Ansatz finde am "fairsten", da er weder den Fortschritt behindert indem er übermäßig lange an alten Zöpfen festhält, noch Benutzer dazu zwingt, von jetzt auf nun ihr ganzes Projekt umzustellen oder auf Gedeih und Verderb der alten (möglicherweise nichtmal mehr gepflegten) Version ausgeliefert zu sein.

Und nu sag ich nix mehr zu dem Thema, da's für den Fred hier nu endgültig OT wird :)

LG

McCavity
 
AW: BASS-Library

Zum Einen hätte ich es besser gefunden, wenn der Entwickler das durch einen großen Versionssprung kenntlich gemacht hätte (also direkt auf 3.0) und (falls nötig) die alte Version mit weiteren 2er Updates. Aber gut, ist sein Nummerierungssystem, ich finde nur, solche Sprünge rechtfertigen eine Große Versionsnummer, selbst dann, wenn nicht auch neue Features mit drin sind.

Das würe allem widersprechen, was in Programmiererkreisen üblich ist. Die Major-Version ändert sich nicht, nur weil einige Calls in der API wegfallen oder dazukommen

Zum zweiten reißt er dadurch, daß die alten Calls komplett aus der API verschwunden sind, allen Entwicklern, die darauf aufbauen, den Teppich unter den Füßen weg. *jeder*, der die neue Version nutzen will, *muß* seine Software umschreiben.

Stimmt, sowas nennt sich "Fortschritt". Und wenn ein sog. Programmierer damit nicht klar kommt, soll er wieder spielen gehen.

BTW: Wir sind voll beim Thema, denn das Topic ist "BASS-Library"
 
AW: BASS-Library

Stimmt, sowas nennt sich "Fortschritt". Und wenn ein sog. Programmierer damit nicht klar kommt, soll er wieder spielen gehen.

Das, was ich meine, nennt sich "Rückwärtskompatibilität". Wenn Du in Deiner Scriptsammlung etwas veränderst, änderst Du also auch die Funktionsaufrufe, so daß alle, die Deine Scriptsammlung schon benutzen und die neue (minor!) Version verwenden wollen, ihre Webpräsenzen umgestalten müssen? Bei den Internetradiovorstellungen ist Dir Professionalität immer sehr wichtig und gerade hier, in "Deinem" Metier, ist das auf einmal nicht nötig? Bitte nicht als Provokation auffassen, ich verstehe das wirklich nicht. Ich arbeit seit '96 selber als Programmierer und lehre mittlerweile Programmierung, vom einfachen Codeschnipsel bis hin zur Architektur und *überall*, wo ich gearbeitet habe, sobald mehr als nur ein Abnehmer für das Produkt existierte, war es eiserne Regel, daß man alles, was auch nur möglicherweise von anderen genutzt wird, nur mäßig ändert, wenn die API betroffen ist. Natürlich müssen alte Zöpfe raus, eine genauso eiserne Regel. Aber wie der Mittelwert zwischen diesen beiden extremen gefunden wurde, das war der einzige Unterschied zwischen den einzelnen Firmen, für die ich tätig war.

Ein Beispiel: ich habe an einer TerminalEmulation für TN3270, TN5250 und BS200 mitgearbeitet. Alle drei benutzen Eingabe- und Ausgabefelder (Dialogorientiert). Unsere Software brachte nun eine Library mit, mit deren API der Kunde seine Dialogseiten "verschönern" konnte. Gnaz krasses Beispiel: die schlimmste Eingabemaske, die ich je gesehen habe, war von einer Versicherung. 80(!) Eingabefelder auf *einem* 80x24-Bildschirm, d.h. die Benennungen (Ausgabefelder) waren kryptische Kürzel. Effektiv war diese Anwendung nur von gut ausgebildeten Datnverarbeitern zu nutzen. Unsere Software hat es erlaubt, diese Anwendung als Webseite darzustrellen, die Kürzel durch "sprechende" Bezeichnung zu ersetzen und so die Anwendung einem wesentlich größeren Anwenderkreis zugänglich zu machen. Grundlage der "Widgets", die wir dabei programmiert haben, war zunächst das Java-AWT, später haben wir dann auf Swing umgestellt - und oh Wunder, mit Ausnahme vom Aussehen und einiger neuer Funktionen hat der Kunde nichts von der Transition bemerkt, weil die älteren Calls alle noch funktioniert haben. Die waren am Anfang dann teilweise etwas umständlich und nach etwa einem Jahr haben wir die dann auch rausgeworfen - aber eben schön vorher angekündigt.

Unsere Kunden waren damals überwiegend Banken und Versicherungen mit Benutzerzahlen, die überwiegend 4-stellig, teilweise sogar 5-stellig waren. Glaubst Du wirklich, die hätten unser Produkt weiterbenutzt, wenn wir denen die API unter'm Hintern weggeschossen hätten? Gab genug Konkurrenten am Markt, die ähnliches geleistet haben, wie wir.

Egal. Wenn Du den Punkt, den ich hier mache, nicht siehst, dann laß uns einfach akzeptieren, daß wir hier verschiedener Meinung sind. Daraus jetzt'n Glaubenskrieg zu machen ist es wirklich nicht wert.

LG

McCavity
 
AW: BASS-Library

Wenn ein *Endbenutzer* ein Produkt mit einer inkomptatiblen API-Version zu betreiben versucht, ist das in der tat sein Problem. Aber davon habe ich auch gar nicht geredet.

Naja doch. Das war der Ausgangspunkt des wieder zum Leben erweckten Threads: rabesocke brauchte das BASS-AAC-Plugin, weil es das derzeit nur noch in Version 2.4 gibt, hat er zwangsweise auch die BASS.DLL 2.4 dazu installiert, und die ist nicht mit mAirList 2.1 kompatibel.

Deswegen weiß ich nicht, wie du dann darauf gekommen bist, gegen den Library-Programmierer zu wetten. Der hat sich nichts zu schulden kommen lassen. Außer vielleicht, dass er die alten Plugins nicht mehr zum Download anbietet. Das ist echt blöd.

Zum zweiten reißt er dadurch, daß die alten Calls komplett aus der API verschwunden sind, allen Entwicklern, die darauf aufbauen, den Teppich unter den Füßen weg. *jeder*, der die neue Version nutzen will, *muß* seine Software umschreiben.

Und wenn er sie nicht nutzen will, dann nutzt er halt noch die alte und liefert einfach die passende DLL mit dazu aus. Mal von dem Plugin-Problem abgesehen ist kein Programmierer gezwungen, das Update mitzumachen.

Meinen Lösungsansatz dazu hatte ich ja schon beschrieben: Alte Calls (und Returnwerte) ändern sich zunächst einmal *nicht* sie werden aber ab sofort in der Dokumentation als "deprecated" geführt.

Damit verschiebst du das Problem nur, denn spätestens ...

bis dann die alte irgendwann rausgelöscht wird.

... funktioniert alles nicht mehr.

Mein Fazit: API-Änderungen, auch "plötzliche", sind kein Problem, solange der Entwickler der darauf aufsetzenden Software selbst entscheiden kann, welche API er verwendet und auf welche Library-Version er aufbaut. Da die BASS.DLL in der Regel einfach beim End-Programm mitgeliefert wird und nicht vom Endbenutzer getrennt installiert werden muss, stellt das kein größeres Problem da: dem Benutzer kann egal sein, welche Version da werkelt. Hauptsache, sie passt zur verwendeten API. Lediglich die Plugins sollten noch in den alten Versionen verfügbar sein.


yps
 
AW: BASS-Library

Ich weiß jetzt nicht, was an meiner Frage so schlimm war? Ich wusste nicht, dass sich in dieser neuen Version so viel verändert hat. Und da ich die AAC.dll brauchte, um meine Files abspielen können, habe ich das gesucht und natürlich direkt beim Hersteller gefunden. Da das Plug-In dann nur mit der Version 2.4 funktioniert, habe ich eben die neue BASS.dll installiert. Ich wusste nicht, dass das ein Problem hervorruft und ich durch meine Frage gleich der Böse bin. Ich habe nunmal nicht die Erfahrung und das Wissen über solche dll's und ja, ich habe es "blind" installiert in der Annahme, dass es geht. Ich habe nie gesagt, dass ich irgendjemand die Schuld gebe, dass es nicht funktioniert!
Im Endeffekt war es nunmal so, dass es nicht funktionierte und fragte somit nach, ob es ein Problem bei mir war oder die neue Version der BASS.dll nicht mit der aktuellen Version von mAirList zusammen arbeiten kann. Nicht mehr und nicht weniger. Und ich habe meine Antwort bekommen und finde das ok und versuche, die AAC.dll in der Version 2.3 zu bekommen.

Beste Grüße euch und schönen Tag,
Christian
 
AW: BASS-Library

Deswegen weiß ich nicht, wie du dann darauf gekommen bist, gegen den Library-Programmierer zu wetten.
Ich wettere ich nicht gegen den Library Programmierer im speziellen, sondern gegen diese Praxis im Allgemeinen - und genau deshalb hatte ich den Ursprungsbeitrag ursprünglich auch als OT gekennzeichnet, weil es eben *nicht* nur um die BASS.dll ging, sondern das als allgemeiner Denkanstoß gedacht war.

Und wenn er sie nicht nutzen will, dann nutzt er halt noch die alte und liefert einfach die passende DLL mit dazu aus. Mal von dem Plugin-Problem abgesehen ist kein Programmierer gezwungen, das Update mitzumachen.
Natürlich nicht. Aber warum erneuert man Libraries? Um alte Fehler zu beseitigen und neue Funktionalität einzubauen, richtig? Und jeder Programmierer, der so eine Library verwendet und seine Software weiter pflegt tut dasselbe - und wird früher oder später auch die neue Funktionalität der Library verwenden wollen und *muß* dann einen großen Teil seiner Software ändern, damit sie mit der neuen Library zurechtkommt. Verstehst Du, was ich meine? Obwohl ich vielleicht nur *eine* neue Funktion verwenden will, muß ich u.U. 10 Stellen meines Programms ändern, die bisher anstandslos gelaufen sind.



Damit verschiebst du das Problem nur, denn spätestens ...

[...]

... funktioniert alles nicht mehr.
Das ist nicht ganz richtig. Ich habe geschrieben, daß in der Dokumentation die Löschung der alten API anzukündigen ist. Wenn jetzt also ein Programmierer die Doku nicht liest, dann hast Du Recht und er wird sich irgendwann wundern, warum seine Calls ins Leere laufen ([OT]Thou shalt not follow the Null pointer for horrible things and utter chaos await thee at it's end ;)[/OT]). Wenn er aber die Dokumentation tatsächlich liest, dann weiß er lange genug im Voraus, daß er irgendwann in der Zukunft umstellen müssen wird - aber der Zeitpunkt ist ihm selbst überlassen und er kann die Änderungen ausgiebig testen.

Mein Fazit: API-Änderungen, auch "plötzliche", sind kein Problem, solange der Entwickler der darauf aufsetzenden Software selbst entscheiden kann, welche API er verwendet und auf welche Library-Version er aufbaut. Da die BASS.DLL in der Regel einfach beim End-Programm mitgeliefert wird und nicht vom Endbenutzer getrennt installiert werden muss, stellt das kein größeres Problem da: dem Benutzer kann egal sein, welche Version da werkelt. Hauptsache, sie passt zur verwendeten API. Lediglich die Plugins sollten noch in den alten Versionen verfügbar sein.
Für den Endbenutzer Full ACK. Aber ich habe den Endbenutzer nur im Nebensatz erwähnt, denn mir ging es um den Entwickler der Software, der auf die Library aufsetzt. Und der wird sicherlich mindestens gehörig fluchen, wenn sich die API von einer Version zur nächsten komplett ändert. Glaub mir. Been there, done that. :)

LG

McCavity

Ergänzung:
@rabesocke

Irgendwas hast Du hier grob in den falschen Hals bekommen - niemand (zumindest ich nicht, für andere kann ich ja nicht sprechen ;)) sieht Dich hier als den "Bösen" an :) die Diskussion dreht sich gerade um die Entwickler der Library und der die Library verwendenden Software, hat sich also vom eigentlichen Kern der Diskussion etwas entfernt. Du hast Dich im Prinzip richtig verhalten. Das einzige, was Du vielleicht noch hättest besser machen können (falls Du es nicht ohnehin getan hast), wäre, wenn Du vor dem Installieren der neuen Version Dir die Dokumentation genau angeschaut hättest, ob es dort eventuell Hinweise auf nicht mehr vorhandene oder geänderte Funktionalität gibt. Aber "Versuch macht kluch", wie man so schön sagt. Niemand kann alles wissen und wenn für Dich die Informationen aus diesem Thread rausgekommen sind, die Dir helfen, Dein Problem zu lösen, dann ist doch alles schick :)
 
AW: BASS-Library

Das, was ich meine, nennt sich "Rückwärtskompatibilität". Wenn Du in Deiner Scriptsammlung etwas veränderst, änderst Du also auch die Funktionsaufrufe, so daß alle, die Deine Scriptsammlung schon benutzen und die neue (minor!) Version verwenden wollen, ihre Webpräsenzen umgestalten müssen?

Wenn es sinnvoll ist, ja. Und wenn Rückwärtskompatibilität keinen Sinn macht, wird die ignoriert. Das trifft nicht nur auf meine Scripte zu sondern auch auf meine Software in anderen Sprachen, völlig egal ob Perl, C, C++ oder sonstwas.

Die Minorversion versioniert nunmal Änderungen die keine Änderung der Majorversion rechtfertigen. Und das tun API-Änderungen in den seltensten Fällen.

Und wie sich zwanghafte abwärtskompatibilität auswirkt, hab ich am Beispiel von Intel gezeigt. Oder ist dir entgangen, dass wir immer noch auf einer verkappten 4-Bit-Technologie arbeiten, die lediglich so oft aufgebohrt wurde um die heutige Leistung zu erreichen? Wenn ein Entwickler die Kompatibilität über Funktionialität und Geschwindigkeit stellt, ist er ein schlechter Programmierer (und/oder wird von Intel oder Microsoft bezahlt)
 
AW: BASS-Library

@McCavity:
Nein, ich habe es nicht wirklich in den falschen Hals bekommen. Ok, es war vielleicht etwas überspitzt ausgedrückt, aber es hat sich für mich schon ein wenig danach angehört.
Ich habe kein Problem und es ist auch alles gut. Ich habe meine Information bekommen bzw. die Information vom Entwickler hier weitergegeben, falls jemand anderes das gleiche Problem haben sollte.

Danke für eure Mithilfe und beste Grüße,
Christian
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben