HD-rec erweitern

[Berndroesch]

Der letzte Post ist schon ne Weile her bei AIDE, gibts da was neues ?
Ich möchte hd-rec erweitern(mit der PC musik soft geht das auch nicht), aber auf sourceforge sind nur hd-rec files von 2012. aber die gehen mit den neuesten includes wieder nicht mehr. Oder kann es jemand kompilieren ?.

Ich würde in hd-rec plugin api die Abfrage ob eine spur gemutet ist oder nicht und das setzen vom mute status einer Spur einbauen.

Ich würde dann in den bars wrapper 10 Knöpfe einbauen mit denen man für alle
spuren die Mute einstellungen speichern kann und laden kann
dazu muss ich die Werte auch auslesen können.

Sinn des ganzen ist, dass man live am Keyboard spielen kann und einen pattern mode hat,
indem man dann die gemuteten spuren umschaltet während hd-rec in z.b 2
Takte wiederhol mode läuft

So kann man dann verschiedene Spuren machen mit unterschiedlichen Sequenzen.
z.b
Spur 1 bass mit arpegiator sequenz a
Spur 2 Bass mit arpegiator sequrnz b

Spur 11 Drum sequenz a
spur 12 Drum sequenz b
usw. Man kannn auch verschiedene Effekte/ sounds auf die Spuren legen und schnell zum AB vergleich umschalten

Dann mutet man spur 2 und spur 12. 1 und spur 11 stellt man auf on und man speichert
dass per shift left button auf einen Knopf(Namen A) der für die mute
settings ist. Die Knöpfe baue ich in den bars wrapper ein, aber ich brauche
den Zugang zu den Mute status Daten aus Hd-rec

dann stellt man Spur 1 und spur 11 auf mute Spur 2 und 12 auf on
Auf die 2.mute setting (Namen B) setting speichert man dann das.

Die Knöpfe sind auch per midi controller ansteuerbar(so dass man die am
Keyboard mit den tasten dort umschalten kann) und sind somit Takt synchron.
Also das muten oder unmuten passiert immer auf Taktgrenzen. So kann man
dann sowas wie eine Begleitautomatik machen und auch Abwechslung mit
arpegiatoren erzeugen. Ausserdem mache ich dann noch ein String gadget mit
abpielfolge für einen pattern mode. aabbba spielt dann 2* Spur 1+ Spur 11.
und dann 3* spur 2 +Spur 12 dann 1* spur 1+spur 11

Dass Prinzip hat den Vorteil, dass man da viel kreativer sein, kann, z.b
sounds wechseln effekte etc, verschiedene versionen vergleichen und auch
noch live spielen

[Der Wanderer]

AIDE werkelt bei mir ganz gut. Ein paar Features fehlen noch, war gerade dabei die GUI flexibler zu machen dass es auch unter niedrigen Auflösungen nutzbar ist. Wenn Interesse besteht baue ich das weiter aus. Denkt dran, Feedback ist die einzige externe Motivationsquelle...

Das mit dem Muten per PluginInterface kann ich machen, allerdings kann ich nicht versprechen wann ich dazu komme da ich wenig Zeit habe. Demnächst habe ich Urlaub, evtl. geht da was...

[Blackbird]

Ich möchte hd-rec erweitern....

Das mit dem Muten per PluginInterface kann ich machen, allerdings kann ich nicht versprechen wann ich dazu komme da ich wenig Zeit habe. Demnächst habe ich Urlaub, evtl. geht da was...

Passt irgendwie nicht so recht deine Antwort, findest du nicht ?

So wie ich das lese möchte das Bernd selber tun, weil er genau weis das bei dir wegen Zeitmangel es länger dauern wird...

[Der Wanderer]

Vielleicht fehlt etwas Kontext, ich habe auch mit Bernd gemailt. So oder so muss ich mir den Sourcecode anschauen.

[tomsmart1]

Willkommen Bernd,

super das du jetzt auch hier ins Forum gefunden hast

Ich habe mir mal den Sourcecode von HD-REC main angesehen er lässt sich ganz leicht Compilieren wenn du ffa_Save{...} mit ffa_Write{..} ersetzt. Bei MIDI gibt es ein Problem beim zuweisen einer Stringaddresse an einen Pointer da muss entweder gecastet werden oder der Syntaxlevel nach den includes heruntergesetzt werden, sollte für dich kein Problem sein.

offtopic:
Bernd ich könnte deine Hilfe beim Compiler gebrauchen um diesen wieder so umzustellen das er keine FPU befehle wie FMOVE verwendet wenn man nur die integer Optimierung eingeschaltet hat. Das bedeutet das jedes mit Amiblitz erstelltes Programm früher oder später auf Rechner ohne FPU abstürzt egal welche Optimierung man eingestellt hat!

Ich mach dafür ein extra Thema auf zum diskutieren.

[Der Wanderer]

Ich mache ein SVN commit vom aktuellen Code. Ihr braucht ihn nicht selbst zu modifizieren.

[Berndroesch]

wegen dem hd-rec hat Thilo schon direkt geschrieben, so einfach geht es anscheinend nicht. Ich werde dann direkt einen arpegiator/step sequencer für den bars wrapper machen, den man per controller umschalten kann.

das mit dem ohne FPU befehle weis ich selber nicht mehr wo da der code drinsteht. Ich dachte halt im Jahr 2000 wird sich wohl jeder aktive User eine FPU gegönnt haben.

um die stellen zu finden, muss man nach #$f2 im sourcebrowser suchen. dann musste halt deaktivieren und sehen ob es dann geht.aber auch in den init libs sind fpu befehle drin. versteh ich echt nicht weswegen die Mühe sein soll

Ich habe übrigens jetzt einen surround receiver der DTS Neo 6 kann. dass klingt echt super mit dem Hal, besser als pro logic2, weil DTS neo 6 nichts an der stereo Basis der Front kanäle ändert. per stereo spreader im aux, könnte man dass dann auf die rear kanäle legen
was aber wichtig wäre und was ich länger her schon geschrieben habe, dass man auch stereo spreader und die insert effekte im aux nutzen kann und auch die auf effekte als insert effekte

Dort steht wie es funktioniert. vielleicht kannst mal schreiben wie der code für die Formel dafür ist(damit es schnell geht ohne wurzel), damit man es in den stereo spreader einbauen kann und somit das signal auch nach hinten schieben kann

<!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/Matrix_decoder#SQ_matrix_encoding_.282:4.2C_.22Stereo_Quadraphonic.22.2C_CBS_SQ.29">http://en.wikipedia.org/wiki/Matrix_dec ... _CBS_SQ.29</a><!-- m -->

formel ist unten

Dolby Pro Logic II matrix encoding (2:5)

[hackball]

...
das mit dem ohne FPU befehle weis ich selber nicht mehr wo da der code drinsteht. Ich dachte halt im Jahr 2000 wird sich wohl jeder aktive User eine FPU gegönnt haben.
... versteh ich echt nicht weswegen die Mühe sein soll
...

Bernd (willkommen), es ist eben nicht so, daß jeder AmigaUser per se eine FPU hat. Insbesondere wird ja auch überall betont, daß eigentlich nur Raytracer und dergleichen soetwas voraussetzen. Neuere Turbokarten, z.B. die ACAs, haben keine FPU.
Wenn AmiBlitz eine FPU voraussetzt, dann hat es einen Nachteil gegenüber dem alten BlitzBasic; und der Vorteil davon ist genau welcher?
Warum baut man FPU-Code in einen BasicCompiler, anstatt in die FPU-libs? Nur, weil man es kann? :?

[Berndroesch]

Was machst du denn heute noch mit deinem Amiga ohne FPU. DU hast doch mit sicherheit dann einen andren Rechner der eine FPU hat oder nicht ?

Wenn es dir um neue Amiga Software ginge, könntest du es ja auf einer Emulation nutzen.

Flieskommazahlen braucht man oft in einem Programm. Als es noch zu teuer war und somit wenige eine FPU hatten, musste es mit den FPU Libs gemacht werden. das ging bei wenig berechnungen, aber es machte dem Programmierer wieder mehr arbeit, weil sie extra den Code so schreiben mussten, damit Fliskommaberechnungen so weit es geht vermieden werden. Und im Jahre 2000 war eine FPU standard in allen CPU. nur die amiga user wollen es scheinbar nicht einsehen und erwarten von den Programmierern dann noch extra arbeit.
vermutlich wollen es die Amiga User meist nicht einsehen, dass programmieren eine Menge Zeit kostet, und wenn man das letzte aus der hardware rausholen will, dann kostet es noch mehr Zeit. Zeit die einem für neue features dann fehlt. aber zum glück haben es die User auf dem PC sektor eingesehen und kaufen sich Hardware bei der man nicht so viel Zeit mit Code optimierung verschwenden muss, weil zum Glück speed kaum noch ein Problem ist.

Ne FPu braucht man eigentlich immer, wenn etwas mit flieskommazahlen berechnet werden soll. sei es nun das CSS seitenlayout eines browser, ein portiertes Linux spiel etc. alles würde extrem lahm und unbenutzbar wenn man es über eine FPU lib machen würde. selbst die Schüsse berechnen geht viel einfacher, wenn man einen flieskommawert benutzen kann und sagen, die gegnergeschwindigkeit ist 1.34 oder so. nimmt man da 2 wäre der gegner zu schnell, bei 1 bewegt er sich ja garnicht. daher kann auch jeder Taschenrechner fliesskomma und sogar die Preise werden nicht in Ganzzahl angegeben

Wenn AmiBlitz eine FPU voraussetzt, dann hat es einen Nachteil gegenüber dem alten BlitzBasic; und der Vorteil davon ist genau welcher?

dass man in amiblitz eben genauso einfach und schnell rechenintensive Programme schreiben kann, wie software Synthesizer, Audio effekte, 3d games wie anderswo. Blitz basic 2 ist weil es nur über FPU libs geht viel zu langsam. Macht etwa 10-20 fache mehr speed aus, wenn man die FPU direkt benutzt. Für jemand der eh nur Spiele wie vor 25 Jahren machen will, der kann ja dafür Blitz2 nehmen. Leider ist halt die weiterentwicklung der 68k Serie eingestellt worden, und die 68k CPU wird nur noch für simple embedded apps verwendet. Nen Natami mit FPGA und FPU wird es wohl nicht geben.

Neuere Turbokarten, z.B. die ACAs, haben keine FPU.

Es werden welche ohne FPU verkauft, weil es halt einige geizige Amigauser gibt und die integer versionen wegen dem zielmarkt embedded teurer sind und auch weniger takt erlauben

[Der Wanderer]

Ich glaube niemand zweifelt den Nutzen einer FPU an, und heute Systeme haben eine, ja. Es geht einfach darum, dass Amiblitz dadurch das Feature verloren hat Code zu erzeugen ohne FPU (viel gefragtes Feature von Classic HW besitzern), und es ist nicht einsichtig warum sie gebraucht wird, wenn man in seinem Program keine Floats nutzt. Vor allem korrumpiert es aber "optimize 2".

Also wäre es toll, wenn ein "Hello World" ohne FPU auskommt, zumindest wenn "optimize 2" nicht definiert ist. Wofür wird die FPU denn beim startup gebraucht?