Hallo,
damit der Umstieg auf oTx 2.2 nicht "zu plötzlich" kommt, habe ich mich letzte Woche mal etwas strukturierter an die Migration gemacht.
Ich habe das Ziel meine vorhandene 2.18 Konfig soweit anzupassen, dass der Umstieg auf 2.2 dann nur noch die automatisierte Konvertierung der Modellspeicher darstellt.
(auf neudeutsch "nobrainer")
Die Umstellungsarbeiten (Aufwand und Komplexität) hängen natürlich stark von der individuellen Programmierung & Anzahl der Modelle ab.
Alles auf einer Skala von 0-100 ist möglich
Hier mal die Punkte, die mir aufgefallen sind:
(1)
Nomenklatur Kurven-Bezeichner:
Die erlaubte Namenslänge wurde von 6 auf 3 Zeichen reduziert.
ich empfehle daher bereits vor Migration die Namen entsprechend zu ändern, damit sie später 1:1 übernommen werden
Ist ja kein komplizierter Vorgang
(2)
Nomenklatur Globale Variablen
Die Programmierer kämpfen wohl um jedes Byte, auch hier gab es die Kürzung auf 3 Buchstaben,
Vorgehensweise also analog zu (1)
(3)
System soundfiles
Die alten Dateien können grundsätzlich weiter verwendet werden
unter 2.2 ändern sich ein paar Filenamen, keine grosse Sache.
Zudem sind 8 neue files hinzugekommen.
Um bereits jetzt eine 2.2 kompatible Fileversion zu haben, gehe ich folgendermassen vor:
Einfach die csv Dateien mit den Beschreibungen in ein spreadsheet importieren und die Versionen gegenüberstellen:
Die gelb markierten 2.18 Files kopiere ich in ein Unterverzeichnis, benenne sie 2.2 Konform um und kopiere sie zurück.
Dadurch habe ich ein File sowohl 2.18 als auch eines 2.2. konform.
Die orange makierten Files mit den üblichen tools generieren.
Das ganze scheint aus Gründen der Vereinheitlichung diverser Sprachversionen und "Abwärtskompatibilität" verschiedenster HW erfolgt zu sein.
(4)
eigene Soundfiles
das neue oTx lässt da wohl ausschliesslich 6.3 Namenskonvention zu, ergo umbenennen
- auch schnell erledigt-
(5)
SF mit soundfiles
... die müssen jetzt natürlich auf das neue Soundfile umgestellt werden
(deswegen auch die Kopierei unter #3)
- Aufwand je nach Umfang der Benutzung -
(6)
lua scripte
- a - Filename:
Lua scripte müssen sich auch an die 6.3 Konvention halten, ergo umbenennen & an den entsprechenden Stellen der Modellspeicher anpassen
- b- *coding
bis jetzt liefen alle scripte die ich nutze auf Anhieb, Lua wird stark erweitert (schreiben via S-Port und einiges anderes...),
bleibt aber meinen Tests nach völlig abwärtskompatibel
... lediglich Aufrufe von soundfiles müssen ggf. angepasst werden, s.o.
Mehr ist mir bei meinen Kompatibilitätstests erst mal nicht aufgefallen.
Da noch kein final release in Sicht ist, kann sich natürlich noch etwas ändern.
Die Konvertierung auf 2.2 lief unter Companion recht gut, über den Sender (X9e) gab es allerdings u.U. noch kleine Fehler, da sollte man imho noch vorsichtig sein.
P.S.
getestet wurde mit einer X9e
wer mal die 2.2. testen möchte sollte dafür eine dedizierte sdcard verwenden
Insgesamt jedenfalls keine großen technischen Hürden, lediglich Fleissarbeit
damit der Umstieg auf oTx 2.2 nicht "zu plötzlich" kommt, habe ich mich letzte Woche mal etwas strukturierter an die Migration gemacht.
Ich habe das Ziel meine vorhandene 2.18 Konfig soweit anzupassen, dass der Umstieg auf 2.2 dann nur noch die automatisierte Konvertierung der Modellspeicher darstellt.
(auf neudeutsch "nobrainer")
Die Umstellungsarbeiten (Aufwand und Komplexität) hängen natürlich stark von der individuellen Programmierung & Anzahl der Modelle ab.
Alles auf einer Skala von 0-100 ist möglich
Hier mal die Punkte, die mir aufgefallen sind:
(1)
Nomenklatur Kurven-Bezeichner:
Die erlaubte Namenslänge wurde von 6 auf 3 Zeichen reduziert.
ich empfehle daher bereits vor Migration die Namen entsprechend zu ändern, damit sie später 1:1 übernommen werden

Ist ja kein komplizierter Vorgang
(2)
Nomenklatur Globale Variablen
Die Programmierer kämpfen wohl um jedes Byte, auch hier gab es die Kürzung auf 3 Buchstaben,
Vorgehensweise also analog zu (1)
(3)
System soundfiles
Die alten Dateien können grundsätzlich weiter verwendet werden
unter 2.2 ändern sich ein paar Filenamen, keine grosse Sache.
Zudem sind 8 neue files hinzugekommen.
Um bereits jetzt eine 2.2 kompatible Fileversion zu haben, gehe ich folgendermassen vor:
Einfach die csv Dateien mit den Beschreibungen in ein spreadsheet importieren und die Versionen gegenüberstellen:

Die gelb markierten 2.18 Files kopiere ich in ein Unterverzeichnis, benenne sie 2.2 Konform um und kopiere sie zurück.
Dadurch habe ich ein File sowohl 2.18 als auch eines 2.2. konform.
Die orange makierten Files mit den üblichen tools generieren.
Das ganze scheint aus Gründen der Vereinheitlichung diverser Sprachversionen und "Abwärtskompatibilität" verschiedenster HW erfolgt zu sein.
(4)
eigene Soundfiles
das neue oTx lässt da wohl ausschliesslich 6.3 Namenskonvention zu, ergo umbenennen
- auch schnell erledigt-
(5)
SF mit soundfiles
... die müssen jetzt natürlich auf das neue Soundfile umgestellt werden
(deswegen auch die Kopierei unter #3)
- Aufwand je nach Umfang der Benutzung -
(6)
lua scripte
- a - Filename:
Lua scripte müssen sich auch an die 6.3 Konvention halten, ergo umbenennen & an den entsprechenden Stellen der Modellspeicher anpassen
- b- *coding
bis jetzt liefen alle scripte die ich nutze auf Anhieb, Lua wird stark erweitert (schreiben via S-Port und einiges anderes...),
bleibt aber meinen Tests nach völlig abwärtskompatibel
... lediglich Aufrufe von soundfiles müssen ggf. angepasst werden, s.o.
Mehr ist mir bei meinen Kompatibilitätstests erst mal nicht aufgefallen.
Da noch kein final release in Sicht ist, kann sich natürlich noch etwas ändern.
Die Konvertierung auf 2.2 lief unter Companion recht gut, über den Sender (X9e) gab es allerdings u.U. noch kleine Fehler, da sollte man imho noch vorsichtig sein.
P.S.
getestet wurde mit einer X9e
wer mal die 2.2. testen möchte sollte dafür eine dedizierte sdcard verwenden
Insgesamt jedenfalls keine großen technischen Hürden, lediglich Fleissarbeit
Zuletzt bearbeitet: