SpeakJet Board und Applikation

[Rio]

;)

k2mod3.mp3

k2mod5.mp3

k2mod7.mp3

k2mod10.mp3

[MTE]

mehr  ;D

klingt ma echt lustich

[Rio]

8)

k2mod8.mp3

k2mod9.mp3

[Rio]

hier noch ein letztes Beispiel in zusammenspiel mit Beats etc.. und ich hab ne Userseite angelegt:...

http://www.midibox.org/dokuwiki/doku.php?id=rio

k2mod11.mp3

[MTE]

haha wie geil, in nen 64er eingebaut  :D

ist das eines meiner Displays ?

Echt gute Arbeit, bin mal auf den Endsynthie gespannt...werde mir ja in ferner Zukunft auch nen SJ bauen, dann nerv ich euch erstma tagelang  :P

Peace  :)

[Rio]

jo das ist einer deiner displays, stimmt  ;)

ja also die geänderte source sende ich morgen erstmal audiocommander und dann mal schauen...

Beste Grüße, Rio.

[audiocommander]

hey, das klingt super

congrats!

[Rio]

wie gesagt, ich sende dir morgen die applikation und schau dir dann in ruhe die Änderungen an.. ich versuche heute noch alle Änderungen zu dokumentieren..

Wenn du bock hast lies oben nochmal meine letzte Antwort zu dem 1/2Envelope Problem. Bis morgen.

[audiocommander]

Ja, ich schau mir alles an.

Ich bin halt im Moment ein wenig außer Atem, weil ich nächste Woche eine Ausstellung beginnt. D.h. ich bin nicht im Lande und meine SJ-Platine auch nicht. D.h., ich werde erst noch eine Platine bauen und einige Hardware-Regler anschließen, um das Projekt abschließend zu veröffentlichen um dann vielleicht zu neuen Ufern aufzubrechen (Stichwort: SoundGin* ;) )... mal sehen...

*Wäre für dich vielleicht auch ein interessanter Chip, weil er bedeutend mehr Synthie-Möglichkeiten bietet als der SJ. Andererseits hat der SJ eine schönere Sprachausgabe.

Egal, in jedem Fall klingen deine Änderungen sehr gut, so dass ich das in jedem Fall in das neue Release einfließen lassen möchte. Wer immer dann so ein Teil nachbauen möchte, braucht dann 1 Core für die Grundfunktionen (kII), die SpeakJet-Platine und fertig. Dann gibt es diverse optionale Erweiterungen wie ein DIN-Modul, eine SensorMatrix oder dein Keyboard-Projekt. Das ist glaube ich eine gute Sache...

Also: nicht verwundert sein, wenn ich die nächsten Wochen nicht so schnell reagiere wie üblich.

Cheers,

Michael

[Rio]

SoundGin, im Prinzip ähnlich dem SpeakJet, jo im Synth bereich mit 6 differenziert einstellbaren OSCs komplexer, das heisst aber auch das eine komplexere Applkation notwendig wäre.

ich habe grad mal mir die Doku angeschaut, ja gut, aber die Sprachausgabe des Speakjet gefällt mir ebenfalls wesentlich (!) besser als beim SoundGin.

Das hat immer noch Vorrang.

Ich glaub der SJ reicht für meine Zwecke :)

Der SoundGin soll wohl ein Soundchip sein der auch Sprache kann..

Der SpeakJet soll ein SprachChip sein der auch Sound kann..

(dann weiss man welcher chip für welchen Zweck besser zum einsatz kommt)

[audiocommander]

Hallo Rio,

ich hoffe, du genießt noch deinen erholsamen Urlaub :)

(bräuchte ich auch mal)

Nachdem sich nun das Release 0.2.4 der nächsten kII-Version nähert und ich kräftig am bugfixen und Code-aufräumen bin, habe ich mir nun in Ruhe mal deine sämtliche Erweiterungen angesehen. Zuerst wollte ich alles übernehmen (mergen), aber das konnte ich nicht, da deine Erweiterungen teilweise redundant zu meinen Funktionen und bereits existierenden Variablen sind und so einige Funktionen überflüssig würden und es auch sehr viele Überschneidungen in bestimmten Bereichen gibt. Nachdem ich drei Bugs gefixt habe, auf denen ein Großteil deines Codes basierte, bleibt nun nicht mehr so richtig viel übrig, das ich übernehmen könnte:

+ Envelope Settings

Die Option Envelope half-on/off für OSC 4/5 hatte ich im ersten Release übergangen; ich habe das nun sauber neu programmiert; d.h. ich habe nicht deinen Code verwendet, sondern ein Bitfield angelegt und mehrere Controller, mit denen man die verschiedenen ENV-Optionen entweder direkt setzen oder weiterschalten kann.

+ Hanging Notes (NOTE-OFF Bug)

Dieser Fehler hing mit der Harmonisierung zusammen. Ich konnte das Problem lösen; es funktioniert jetzt einwandfrei.

+ Knackser im Anschlag/Lautstärken-Einblendung

Ich habe auch diesen "Effekt" beseitigen können (ich möchte es fast nicht Bug nennen, weil ja nicht jede Note, sondern nur einige wenige betroffen waren) :

Das ganze lag nicht am schnellen Setzen der Lautstärken, sondern am Envelope! Jetzt wird der ENV nach den OSCs gesetzt, und das Knacksen ist weg.

Dadurch gibt es auch keinen Grund mehr für deinen Workaround, die Lautstärken einzublenden um so das "Knacksen" zu vermeiden. Diese Lösung fand ich allerdings auch aus performancetechnischen Gründen nicht so gut. Zumal ich den Verdacht hege, dass das bei dir entstandene Krachen in den höheren Bereichen auf einen Buffer Overflow gründen. Bei mir trat das das von dir beschriebene Problem in höheren Bereichen für den ENV OSC4/5 nie auf.

Außerdem habe ich einen Puffer-Überlauf-Schutz eingebaut; speziell mit dieser Funktion ist es noch wichtiger geworden, mit der Anzahl der gesendeten Werte hauszuhalten.

Dazu kommt, dass ich mit dem ACSyncronizer (midiclock "Umbau") in der neuen Version einen zeitkritischen, timingbasierenden Auftrag für den PIC habe; da muss ich aufpassen, dass alles mehr oder weniger gut getimed ist.

Auch noch erwähnen möchte ich, dass ein weiterer Nachteil deiner Implementation darin bestanden hat, dass das Velocity Setting der Note-On Anschläge komplett ignoriert würde. Für dynamisches Spielen finde ich das allerdings ziemlich wichtig und sinnvoll.

+ Ungestimmter ENV

Dein Ansatz mit dem in der Frequenz nicht angepassten Envelope klingt zwar einigermaßen gruselig; hat jedoch was interessantes :)  Ich werde über eine Implementierung nachdenken... gibt es hier noch jemand anderes, der für soetwas Verwendung hätte (also eine OSC-Synthese mit ungestimmten Envelope)?

+ OSCSynthese

Abgesehen von der Schleifen-Optimierung habe ich mit deinem Code in diesem Punkt leider ein grundsätzliches Problem, da durch die Änderung die Subtraktive Synthese keine solche mehr ist. D.h. der Clou dieser Methode liegt darin, dass ich von der Grundfrequenz ausgehend, mehrere Harmonische berechne und dann bestimmte Harmonische in ganz exakt definierten Lautstärkenverhältnisse anordne (Subtraktive Klangsynthese). Aus diesen durch Lautstärke strukturierten Harmonischen Sinuskurven ergeben sich neue Wellenformen (Saw, Square, Triangle). Diese Wellenformen haben *nichts* mit dem Envelope zu tun; es ist etwas vollkommen Neues, das nur aus der Mischung der Harmonischen entsteht. Mit deinen Änderungen im Lautstärkenbereich wäre diese Methode deshalb nicht mehr funktionsfähig.

Fazit:

Ich könnte mir vorstellen, dass du (anstatt aus der Subtraktiven OSCSynthese etwas zu machen, das sie nicht ist), eine neue, auf einem gänzlich anderen Prinzip aufbauende Soundsynthese entwickelst. Das würde ich dann jederzeit in ein Release übernehmen – vorausgesetzt, es ist einigermaßen einfach zu implementieren, also hat sinnvolle Variablen/Funktionsnamen, ist funktionell gut vom rest abgegrenzt und dadurch gut verkapselt. Für sowas sollte dann auch eine neue SJCH_Channelvariable definiert werden, die dann diese Funktion zu einer macht, die per Midi-Kanal ansteuerbar ist. Also:

- eigene SJCH_Channelnummer: z.B. SJCH_RIOSynth

- eigene Funktion: IIC_SPEAKJET_RioSynth()

- eigene Variablen: rs_env_mode, rs_whatever usw...

Es sind im Augenblick ohnehin einige SJCH_Cannels mit ziemlich überflüssigen Funktionen belegt (SJCH_Consonants z.B.), da kann gerne noch was sinnvolles kommen...

Das kann ich dann mit drei Copy & Paste Vorgängen übernehmen, ohne mich erst zeitaufwändig um die Implementierung kümmern zu müssen. Es ist nämlich auch ziemlich schwierig fremden Code zu integrieren, der über mehrere Dateien verteilt ist, wenn ich nicht 100% durchsteige was da exakt passiert und die verschiedenen Variablen sehr ähnlich benannt und in ihrer Funktion nicht unmittelbar zu identifizieren sind: z.B. env_waveshape, env_state, env_mod, env_slide, (envelope) mode; dazu kommen noch env_freq und env_value. Es ist echt schwierig da noch durchzublicken...

Außerdem ist es nicht optimal, wenn eine Basis-Methode (IIC_SPEAKJET_ENVFreq), die von anderen Funktionen benutzt wird, verändert wird. Besser, diese (experimentellen) ENV-Änderungen eigens in einer separaten Funktion unterzubringen... so, wie du es mit IIC_SPEAKJET_OSCPlay und _MultiPlay gemacht hast.

Alles in allem danke ich dir für die vielen guten Hinweise.

Ich werde in den nächsten Tagen im englischen SpeakJet-Thread eine Beta veröffentlichen; es wäre nett, wenn du mir Bescheid gibst, ob die mit deiner K64-Tastatur funktioniert. Erst wenn ich dein Feedback habe, werde ich das Release is Wiki setzen (und wie immer: keine Eile ;) )

Viele Grüße,

Michael

[Rio]

ich hoffe, du genießt noch deinen erholsamen Urlaub

danke, bin schon zurück

Zuerst wollte ich alles übernehmen (mergen), aber das konnte ich nicht, da deine Erweiterungen teilweise redundant zu meinen Funktionen und bereits existierenden Variablen sind und so einige Funktionen überflüssig würden und es auch sehr viele Überschneidungen in bestimmten Bereichen gibt.

bitte genau aufschreiben was redundant ist. Meineserachtens wüsste ich jetzt nicht, welche der Variblen redundant sein sollten. Die haben alle ihre eigenständige Funktion.

+ Envelope Settings

+ Hanging Notes (NOTE-OFF Bug)

+ Knackser im Anschlag/Lautstärken-Einblendung

muss ich mir anschauen...

Das ganze lag nicht am schnellen Setzen der Lautstärken, sondern am Envelope! Jetzt wird der ENV nach den OSCs gesetzt, und das Knacksen ist weg.

mhh.. also das Knacksen fiel mir vorallem auch bei ausgeschalteten ENV auf, aber ebenfalls wenn der ENV davor oder dahinter gesetzt wurde. na muss ich mir mal deine änderungen anschauen...

Wäre eventuell cool, falls es bei mir dann immernoch knackt, wenn du mal ne kleine Sequenz einspielen kannst, so dass ich mir das mal anhören und vergleichen kann..

Jedes vermeiden des Workarounds ist natürlich nur zu begrüßen. Obwohl ich das auch im Phrasolator getestet hab und dort kam es bei starken Lautstärkenwechsel (nicht durch den slide mittels Scrollbar, sondern durch direkte lautstärkensprünge) auch zum knacksen.

Auch noch erwähnen möchte ich, dass ein weiterer Nachteil deiner Implementation darin bestanden hat, dass das Velocity Setting der Note-On Anschläge komplett ignoriert würde. Für dynamisches Spielen finde ich das allerdings ziemlich wichtig und sinnvoll.

..wird doch gar nicht ignoriert! hab ich doch ausgiebig getestet. Hast du die K2mod mal auf einen PIC geladen oder nur über den Code geschaut?

Ansonsten beschreib mir bitte die Stelle und bei welchen Einstellungen das ignoriert wird.

+ Ungestimmter ENV

Dein Ansatz mit dem in der Frequenz nicht angepassten Envelope klingt zwar einigermaßen gruselig;

gruselig? mhh... um maximale Möglichkeiten in der Klangsynthese zu bieten, sollte alles getrennt einstellbar bleiben.

+ OSCSynthese

Abgesehen von der Schleifen-Optimierung habe ich mit deinem Code in diesem Punkt leider ein grundsätzliches Problem, da durch die Änderung die Subtraktive Synthese keine solche mehr ist.

?? versteh ich nicht... bei MOD 6 ist deine OSCSynthese 100% implemtiert. Den MOD kann man ja durch den CC einstellen. MOD 1..5 schaltet einfach die OSCs zu und hat mit deiner OSCSynthese erstmal nichts zu tun. Das sind zwei verschiedene Dinge. Erst ab MOD 6. Jedoch ist es möglich den SpeakJet für 1..5 für jeden OSC einzeln zu stimmen. Für meine K64 Applikation ist das unabdingbar.

Außerdem ist es nicht optimal, wenn eine Basis-Methode (IIC_SPEAKJET_ENVFreq), die von anderen Funktionen benutzt wird, verändert wird. Besser, diese (experimentellen) ENV-Änderungen eigens in einer separaten Funktion unterzubringen... so, wie du es mit IIC_SPEAKJET_OSCPlay und _MultiPlay gemacht hast.

kann ich gut nachvollziehen. Na hier lag speziell das problem, dass die Basisfunktion "notenweise" die Änderungen vorgenommen hat. Bei der modifizierten funktion kann auch schrittweise der ENV geändert werden.

Alles in allem danke ich dir für die vielen guten Hinweise.

Ich werde in den nächsten Tagen im englischen SpeakJet-Thread eine Beta veröffentlichen; es wäre nett, wenn du mir Bescheid gibst, ob die mit deiner K64-Tastatur funktioniert. Erst wenn ich dein Feedback habe, werde ich das Release is Wiki setzen (und wie immer: keine Eile)

ja wir testen das mal, wie gesagt. Dann kann ich auch den Aufwand abschätzen. Für die K64 sind zum Beispiel alle neuen CCs unabdingbar, denn diese agiert genau mit den Parametern (end_slide, env_mod, env_type... um den SpeakJet zu Stimmen, gespielte Frequenzen der Noten zu halten oder zu spielen, Volumensettings und Frequenzen individuell für jeden OSC einstellen und auf relativer basis damit spielen... etc. Hör dir einfach die Soundbeispiele an, das waren nur ein paar fixe versuche)

Von daher kann ich nur sagen falls sich unsere vorstellungen gänzlich unterscheiden, werd ich sicherlich nicht ewig dran rumpfeilen bis es irgendwie halbwegs passt, sondern dann einfach die Modifizierung bestehen lassen.

Hast du denn die neuen CCs mit integriert und die modifizierten Funktionen mit angepasst?

Ich habe mich bemüht, dass alle Möglichkeiten deiner K2 Applikation auch in den neu geschriebenen Funktionen enthalten sind... (außer das MDA_STOP für OSCs, das wird ja nun über das Volumen der OSCs gesteuert).

Ich möchte erstmal das neue Release von dir testen und dann kann man weiter sehen.

Sind die CCs jedoch nicht enthalten, müsste ich dann eine neue Anpassung machen usw... und hab auch keine ahnung ob du das dann übernimmst.

Also gib einfach bescheid..

[audiocommander]

Hallo Rio,

also, nein, unsere Vorstellungen unterscheiden sich, denke ich, grundsätzlich nicht – solange nicht unnötig IIC-Nachrichten generiert werden, die leicht zu einem Pufferüberlauf führen könnten.

Wie schon gesagt, ich habe beim Versuch, die Sachen zu übernehmen, irgendwann die Übersicht verloren. Es ist ja immer schwierig Code von anderen zu verstehen... Wenn du mir eine Version mit klaren Benennungen und abgekapselten Funktionen geben kannst, werde ich das sofort diskussionslos übernehmen.

Das Problem ist halt einfach, dass ich (z.B.) nicht genau weiß, was mit env_slide, env_mod, env_mode, env_state auf sich hat. Es fehlen auch Kommentare an der Deklaration, die das detailliert erklären würden.

Verschärft wurde das ganze Dilemma noch, da ich gerade beim ENV eine vorher von mir mies programmierte und buggy Stelle schön neuprogrammiert habe (durch das saubere Bitfeld):

Und das meine ich dann auch mit "redundant": Du hast einige meiner Bugs gefixt und ich habe diese nun noch einmal weitestgehend detailliert überarbeitet - dadurch ergeben sich Überschneidungen:

- ENV Settings (alt: HalfEnveloped for OSC4/5 ging nicht, du hast's gefixt, ich habe die ENVCtrl komplett neu geschrieben; damit können jetzt alle ENV settings in einem Bitfield gespeichert und auch auf einen Rutsch übertragen werden)

- Harmonized Input (alt: ich hatte einen NOTE_OFF-Bug, du hast beim Fixen einen NOTE_ON-Bug daraus gemacht; auch hier habe ich das fixen können und habe aber irgendwo gelesen, dass das Volumensetting deaktiviert ist? ...dachte ich zumindest, sorry falls ich mich hier getäuscht habe).

Und dann bin ich ja auch nicht perfekt; manchmal fliegen alte Definitionen rum oder es gibt auch bei mir nicht ganz 100% exakte Namen. Aber wir müssen das halt irgendwie vereinheitlichen... ich bin da auch für Vorschläge oder Kritik offen.

Schau dir einfach mal in Ruhe die neue Version an (v.a. meine Bugfixes). Ich fände es super, deine Erweiterungen zu übernehmen, aber ich habe einfach keine Zeit, den Code so detailliert zu analysieren, dass ich alles verstehe und dann neuzuprogrammieren... und das ist ja auch nicht Sinn und Zweck der Sache.

Da ich noch länger am Quellcode entwickeln möchte, muss ich darauf achten, dass alles ordentlich benannt und wohlüberlegt getrennt ist, damit man sich in zwei Jahren auch noch auskennt. Wenn alles super läuft, könnte ich z.B. nur durch die Anpassung der Kernfunktionen einen Port für den SoundGin machen :) ...aber das ist noch Zukunftsmusik...

lg

Michael

ps: ich habe gestern ein kurzes Video aufgenommen, das spiele ich heute irgendwann im englischen Forum hoch; das zeigt auch die Sync-Features.

[Rio]

Wie schon gesagt, ich habe beim Versuch, die Sachen zu übernehmen, irgendwann die Übersicht verloren. Es ist ja immer schwierig Code von anderen zu verstehen... Wenn du mir eine Version mit klaren Benennungen und abgekapselten Funktionen geben kannst, werde ich das sofort diskussionslos übernehmen.

Das Problem ist halt einfach, dass ich (z.B.) nicht genau weiß, was mit env_slide, env_mod, env_mode, env_state auf sich hat. Es fehlen auch Kommentare an der Deklaration, die das detailliert erklären würden.

ok verstehe... ich muss unbedingt dir Photos (weil video kann ich nicht aufnehmen) von den Funktionalitäten der K64 mal machen und genaue Beschreibungen der abläufe.. ich weiss auch das die variablennamen nicht alle günstig benannt sind (sie sind jedoch nicht redundant zu deinen variablen) und es ist mir auch klar das ohne das hintergrundwissen was diese funktionen / variablen bezwecken, dir die zusammenhängen dann fehlen (und evtl. das eine oder andere nicht als sinnvoll erscheint). Fakt ist das die K64 mit der älteren modifizierte K2 app. ausgezeichnet funktioniert und ich schon die sachen so mit übernehmen möchte.. falls es jedoch doll einer verallgemeinerung in der neuen K2 wiederspricht.. spricht doch auch nichts gegen einen kleinen abkömling von mir, den ich als K2mod veröffentliche - um sich nicht gegenseitig mit allzuviel programmierarbeit(!) zu belasten (Stryd1 macht es ja auch mit seiner eigenen Seq App.).

Ich weiss auch nicht wer denn alles sonst hier noch mit dem speakjet rumhantiert.

Wahrscheinlich werde ich erstmal deine Applikation zum laufen bringen wollen, weil das hat gestern noch gar nicht geklappt.. und dann muss ich ich schauen wie der mod. code in den neuen sachen miteinfließen kann. ich will nur sagen, falls es zu kompliziert wird, lass ich einfach die modifizierung in der alten k2... aber erstmal schauen ;)

schau dir einfach mal in Ruhe die neue Version an (v.a. meine Bugfixes).

ja ich hab schon gesehn das du einige sachen komplett neu strukturiert hast...

Best grüße Rio.

[Rio]

compilieren ging jetzt (musste noch alle ht. im LCD Tick deaktivieren), aber..

+ Envelope Settings

mit welchem CC kann man den Envelope zuschalten/ausschalten?

hab bisher nichts gefunden..

+ Hanging Notes (NOTE-OFF Bug)

es hat sich für Channel 2 nichts geändert.

Die gespielten allophones können immer noch hängen bleiben.

Schreib mir bitte mal auf, wo der NOTE-OFF Bug bei dir gefixt ist..

+ Knackser im Anschlag/Lautstärken-Einblendung

sind IMHO immernoch enthalten, fällt halt nur bei manchen Envelope einstellungen nicht so auf.

zumal mir folgendes auffiel: Irgendwie scheint in der neuen Applikation in einem längeren Interval oder auch beim schnellen Spielen hintereinander ab und zu und mitten drinn die "Ready" Phrase (oder was anderes) zu spielen. das sollte natürlich nicht sein.

Also bisjetzt hat sich im Zusammenhang mit meiner App. das ganze nicht wesentlich verbessert, sondern ich müsste nun alle modifizierten Sachen neu integrieren und das würde ein Haufen zusätzliche Arbeit machen, zumal ich eigentlich mit der K2mod soweit leben kann... Andererseits ist das workaround in meiner App. zwar zeitkritischer, aber angenehmer als das knacken...

aber das würde ich mir dann nochmal durch deine testaufnahme ohne zugeschalteten envelops anhören, ob das bei dir auch so klingt.

Was natürlich gründe dafür sind, den Code anzupassen:

- der erweiterte Harmonizer

- Codeoptimierung

- überwachung des halfbuffer full (wie fängst du das ab?)

- alles-in-einem Applikation

Ich bin mir nicht sicher, wann und ob ich die extra Anpassung machen kann. Also ob sich der Aufwand jetzt hier wirklich lohnt(?), denn ich konnte bisjetzt noch keine wesentlichen vermeidung der bugs feststellen, welches die workarounds aufheben... .. zumal ich auch im Synthbereich ein bischen einen anderen Ansatz habe:

ich erklär jetzt mal kurz mit weniger technischen Infos:

die OSC 1..5 können in den Ch 11..15 beliebig gestimmt werden. halt wie ne gitarre mit ihren seiten. (da kann man sich sonst was ausdenken - und es kommen auch interessante sachen zustande - das hört man ja an den soundbeispielen).

Der envelope kann belieben zugeschaltet werden oder nicht. Entweder gar nicht aktiv, oder für die OSC 1..3, für OSC 4..5 oder für alle aktiv.

Wichtig ist mir aber die option des abgeschalteten ENV, denn die reinen Sinuskurven lassen sich wunderbar bearbeiten.. sehr störend ist dagegen ein knacken am beginn oder ende des gespielten ton. Darum das workaround. ich hab dagegen noch einen HOLD-Modi per CC implementiert, um auch die Möglichkeit zu haben die gespielten Tönen zu halten und explizit die lautstärken der OSCs einzustellen (dieser Modi ist natürlich nicht groß zeitkritisch, weil hier ja keine extremen lautstärkeänderungen auftreten). Darum hab ich auch nie mit MDA_STOP gearbeitet, sondern nur mit den einzelnen Volumenwerten der OSCs..eventuell setzt ich mal ein workaround unter verwendung des Mastervolumen um, das sollte ja dann wesentlich schneller ablaufen.

Im Channel 16 kann man das ganze gebilde dann relative als akkord spielen. Mit MOD 1..5 sind die gestimmten OSCs zuschaltbar, MOD 6 würde total unabhängig davon deine OSCSynthese aktivieren. In der K64 ist auch ein polymodus, wo die OSC polyphon gespielt werden können integriert (das klingt bei dezenten Envelope Werten oder reinem Sinus interessant).

Zusätzlich kann der Envelope über drei verschiedene Angaben eingestellt werden (env_slide):

       

ON  schwingt mit der OSC Freq.

REL  schwingt relative zur OSC Freq., also kann man relativ zu allen gespielte Note verschieben - oder halt um die Noten schwingen lassen.

OFF total unabhängig von den gespielten Noten.

Bei meiner Umsetzung hab ich mich oftmals an den Möglichkeiten des Phrasolator Programm gehalten, da man hier im Synth bereich genau die Sachen differenziert / explizit einstellen kann. Alle oben beschriebenen Parameter lassen sich sehr einfach in der K64 Applikation einstellen und macht vorallem damit am meisten Sinn. Die K64 ist noch nicht fertig und ich wollt eher daran weiterarbeiten.. alles andere würde mich nun um wochen arbeit zurückwerfen...

ich will damit nicht sagen, dass eine integration undenkbar ist, sondern sich der Arbeitsaufwand nicht ganz ohne wäre.. es wären dabei einige sachen auch zu überdenken, workaround oder nicht etc. Ich würde vielmehr mal in der Zeit ein Workaround mittels Mastervolumen testen.. um die Sache zu beschleunigen...

Eventuell wäre eine integration auch später denkbar (also nach den jeweiligen Releases), wenn alle sachen 100% funktionieren / getestet / durchdacht sind.. (meine idee)

[audiocommander]

Hallo Rio,

compilieren ging jetzt (musste noch alle ht. im LCD Tick deaktivieren), aber..

2x16 wird noch nicht unterstützt; bei mir hängt momentan ein 2x8 dran

aber danke für den Hinweis.

+ Envelope Settings

mit welchem CC kann man den Envelope zuschalten/ausschalten?

hab bisher nichts gefunden..

findest du in "IIC_SPEAKJET_MidiDefines.h";

wenn _TGL (Toggle) meint: weiterschalten (<64/>64), ansonsten den Wert mit evnt2 setzen. Damit sollten alle Envelope-Settings einfach und detailliert anzusteuern sein.

// ENV controls
#define SJCC_ENV_OSC_A			53	// ENV on/off for OSCs 1 to 3
#define SJCC_ENV_OSC_B			54	// ENV on/off for OSCs 4 and 5 (half enveloped only)
#define SJCC_ENV_OSC_TGL		52	// toggle ENV on/off for OSC groups (00, 01, 10, 11)
#define SJCC_ENV_WAVESHAPE		116	// set ENV Waveshape 1:0..31, 2:32..63, 3:64..95, 4:96..127
#define SJCC_ENV_WAVESHAPE_TGL	51	// switch to next envelope waveshape, also see SJCC_ENV_TYPE
#define SJCC_ENV_FREQ			106

+ Hanging Notes (NOTE-OFF Bug) es hat sich für Channel 2 nichts geändert. Die gespielten allophones können immer noch hängen bleiben. Schreib mir bitte mal auf, wo der NOTE-OFF Bug bei dir gefixt ist..

Ach das meinst du, ich meinte den Synth-Modus wenn der Harmonizer zugeschaltet ist (der ist bei dir auch noch drin, zwar anders, aber noch vorhanden). Beispiel: NoteA ist durch die Harmonisierung die gleiche wie NoteB => A down (an) -> A up (aus) -> B down (an) -> B up (aus) => OK A down (an) -> B down (noch an) -> A up (aus) -> B noch down aber kein Ton => Falsch Das ist nun behoben. Das was Du meinst (haben wir aber schon mal weiter vorne im Thread besprochen), ist ein Feature um die Allophone abzukürzen und um sie "in-Time" spielen zu können: Phoneme werden im MSA Modus übertragen und im Input Buffer gespeichert, und dann nacheinander abgespielt. Jedes Phonem hat eine definierte Dauer (siehe Datasheet). Wenn man nun zügig hintereinander mehrere Tasten drückt, kommt es spätestens ab dem dritten Phonem zu einem merklichen Zeitversatz. Deshalb wird beim Note-Off ein MSA_Stop() gesendet, der Buffer wird geleert und alles ist Echtzeit. Solltest du nun einmal eine Taste extrem schnell loslassen, kann es zu einem Hänger kommen, wahrscheinlich weil der Buffer gelöscht wird (sofort per SCP-Command) und das mit einem gepufferten MSA-Kommando zusammenfällt. Ich werde mir das bei Gelegenheit genauer ansehen (denke, dass man das u.U. auch beheben kann). Man kann natürlich auch einen neuen Channelmode mit gepufferter Übertragung ohne Stop anlegen...

+ Knackser im Anschlag/Lautstärken-Einblendung sind IMHO immernoch enthalten, fällt halt nur bei manchen Envelope einstellungen nicht so auf.

Ich habe ein mp3 der Oszillatoren erst ohne, dann ENV_OSC1-3, dann halbENV_OSC4-5, dann OSC1-5 ENV angehängt. Und das für alle OSCs (also insgesamt 4 * 5 snippets). :o Oh mann, ich glaube, ich habe gerade kapiert, was du meinst: Ich dachte die ganze Zeit du meinst das Knacksen in der OSCSynthese (das ich ja jetzt gefixt habe) – das was du als "Knackser" bezeichnest, ist ganz normal, wenn kein Envelope zugeschaltet ist. Eine oszillierende Sinuswelle fängt ja nicht immer bei 0 an! D.h. die Welle oszilliert vor sich hin (im Chip gibt's einen Quartz, der den Takt gibt) und dann wird eine Frequenz gesetzt und die Lautstärke angemacht; wenn die Welle nun nicht am Nullpunkt, sondern in einem anderen Schwingungsstartpunkt "angeht", dann ist das u.U. als Geräusch hörbar; so wie wenn du eine Audiodatei/Wellenform nicht am Nullpunkt schneidest, sondern mittendurch! So, jetzt kommt das beste: Die Übersetzung des Wortes "Envelope" ist Hüllkurve. Mit deinem "Volume-Ramping" machst du also nichts anderes einen Envelope zu programmieren - als "Workaround" für einen "Bug" der keiner ist! Und du darfst ja nicht vergessen, dass ein OSC eine ganz einfache, super-simple Frequenz-Modulation ist. Ich weiß natürlich nicht, was du alles von elektronischer Klangsynthese verstehst (bei mir hält sich das Wissen in Grenzen), aber wir reden hier über einen super billigen Oszillator aus einem 25$ Sprachchip... du kannst das schlecht mit richtigen Synthies vergleichen; da hört man im Normalfall ja nicht einen einzigen Oszillator, sondern eine komplexe Synthese aus mehreren Oszillatoren, Filtern und Envelopes mit komplexen zeitbasierten Hüllkurven-Steuerungen! Also, wenn dir der integrierte Envelope nicht ausreicht, dann wäre es sinnvoller gleich was richtiges zu programmieren. Mit dem ACSyncronizer könnte man jetzt nämlich eine richtig krasse, zeitlich basierte (rhythmische) Hüllkurven hinzufügen.

zumal mir folgendes auffiel: Irgendwie scheint in der neuen Applikation in einem längeren Interval oder auch beim schnellen Spielen hintereinander ab und zu und mitten drinn die "Ready" Phrase (oder was anderes) zu spielen. das sollte natürlich nicht sein.

Wo und wann genau passiert das? Auf welchem Kanal? Ist der Handtracker aktiv? Ist der Garbage-Collecor aktiv? Wenn der Garbage-Collector aktiv ist, dann nimm doch die andere vorkompilierte .syx-Datei (kII_0.2.4.noMessages.syx).

- überwachung des halfbuffer full (wie fängst du das ab?)

Du musst diese Pins miteinander verbinden: SJ:D2 (BufferHalfFull) -> Core:J14 Wenn keine Verbindung besteht, ist der Puffer einfach niemals halb voll.

Ich bin mir nicht sicher, wann und ob ich die extra Anpassung machen kann. Also ob sich der Aufwand jetzt hier wirklich lohnt(?), denn ich konnte bisjetzt noch keine wesentlichen vermeidung der bugs feststellen

Naja, dazu kommt, dass dein Mod zusätzlich zu meinen alten auch noch neue bugs bekommen hat. Genau hierin sehe ich auch eines der größten Probleme, wenn du einen mod veröffentlichst: nämlich, dass alte Bugs weiterbestehen und neue Bugs hinzukommen: 1. Note-ON/OFF bug, harmonizer (s. oben) 2. und mir sind die Harmonischen in der OSCSynthese aufgefallen. Ich weiß nicht warum du da was geändert hast (oder ob das urspünglich mein Fehler war):

	f[0] = freqOfNote[value];
	f[1] = f[0] << 1;
	f[2] = f[1] + f[0]; // f[0] + f[0], nicht f[1] + ff[0]	f[3] = f[0] << 2;
	f[4] = f[3] + f[0]; // 3, nicht 2
	f[5] = f[0] << 3;
	f[6] = f[5] + f[0]; // 5, nicht 4
	f[7] = f[0] << 4;
	f[8] = f[7] + f[0]; // 7, nicht 6

3. Und noch ein Wort zu dem von dir beschriebene Effekt deines Mods (dass es bei höheren Werten mit best. ENV laut zu krachen beginnt). Ich habe mal genau nachgerechnet, wieviele SCP Bytes bei deiner Funktion gesendet werden und bin auf Werte zwischen 20 bis (im Worst Case) mehrere Hundert (!) gekommen. Ich schätze die Wahrscheinlichkeit ziemlich groß ein, dass du den Chip mit seinem 64-byte Puffer einfach überforderst.

Ich meine, ist ja klar, dass es Bugs gibt, wo gibt's die nicht. Aber findest du das wirklich sinnvoll, zwei buggy Versionen rauszuhauen? Sollte man nicht lieber gemeinsam an einer richtig guten Version ohne Bugs arbeiten?

die OSC 1..5 können in den Ch 11..15 beliebig gestimmt werden. halt wie ne gitarre mit ihren seiten. (da kann man sich sonst was ausdenken - und es kommen auch interessante sachen zustande - das hört man ja an den soundbeispielen).

(...)

Der envelope kann belieben zugeschaltet werden oder nicht. Entweder gar nicht aktiv, oder für die OSC 1..3, für OSC 4..5 oder für alle aktiv. Wichtig ist mir aber die option des abgeschalteten ENV, denn die reinen Sinuskurven lassen sich wunderbar bearbeiten..

also, alle OSCs haben eine bestimmte Frequenz und dann machst du nur die Lautstärke an/aus... verstehe ich das richtig?

Kannst du das noch genauer beschreiben?

Ich meine, im Moment kann man NOTE_Ons senden um gestimmte Frequenzen zu erzeugen, ungestimmte Frequenzen kann man per CC wählen. Alle OSCs und der ENV sind per CC separat in Frequenz und Lautstärke einstellbar. Insofern sollte das was du vorhast, ziemlich einfach mit einer entsprechend aufgebauten Midibox zu steuern sein oder aber als gut verkapselte neue Funktion.

Das mit den Envelopes geht ja jetzt alles.

ich hab dagegen noch einen HOLD-Modi per CC implementiert, um auch die Möglichkeit zu haben die gespielten Tönen zu halten und explizit die lautstärken der OSCs einzustellen

Auch das ist (und war immer) möglich. Drücke eine Taste und dann ändere die OSCs per CC (101-105 und 111 bis 115).

Außerdem steht auf meiner Prio-Liste noch die Unterstützung des CC# MIDI Pedal-Hold...

(dieser Modi ist natürlich nicht groß zeitkritisch, weil hier ja keine extremen lautstärkeänderungen auftreten). Darum hab ich auch nie mit MDA_STOP gearbeitet, sondern nur mit den einzelnen Volumenwerten der OSCs..eventuell setzt ich mal ein workaround unter verwendung des Mastervolumen um, das sollte ja dann wesentlich schneller ablaufen.

Ich würde vielmehr mal in der Zeit ein Workaround mittels Mastervolumen testen.. um die Sache zu beschleunigen...

Ich nehme an, du meinst den MSA_Stop(); allerdings weiß ich nicht, was du damit meinst, da alle Synthie-Steuerungen per SCP übertragen werden und MSA_Stop() nur für das Phonem-Triggering per Tasten benutzt wird (m.a.W. es gibt in meinem Code kein MSA_Stop() in Verbindung mit OSCs) ???

und workaround für was? Für die "Knackser" am Anfang?

hab' ich auch nicht verstanden. Aber es würde bedeuten, dass die Velocity des Anschlags flöten geht :-\

Versteh' ich nicht...

Im Channel 16 kann man das ganze gebilde dann relative als akkord spielen. Mit MOD 1..5 sind die gestimmten OSCs zuschaltbar, MOD 6 würde total unabhängig davon deine OSCSynthese aktivieren. In der K64 ist auch ein polymodus, wo die OSC polyphon gespielt werden können integriert (das klingt bei dezenten Envelope Werten oder reinem Sinus interessant).

genau das finde ich aber nicht gut. Das meinte ich im letzten Post mit ("die subtraktive Synthese zu etwas machen, das sie nicht ist").

Du bist dabei, eine Funktion mit etwas komplett anderem zu vermischen, das ist weder gut anzuwenden, noch sinnvoll zu programmieren. Arnie Schwarzenegger hat Unrecht, wenn er empfiehlt: "Mix it, Baby!"

IMHO ist das ja die Haupt-Arbeit am Programmieren: das Aufbrechen von Aufgaben in sinnvolle, von einander getrennte Bereiche.

Was spricht denn konkret dagegen, das in einer _eigenen_ Funktion zu realisieren, anstatt eine andere zu verhutzeln, die etwas ganz anderes sein möchte. Warum malst du den Apfel rot an, wenn du auch eine Kirsche dazu haben kannst... weißt du was ich meine?

- eine Funktion

- einen main.c-call

- ein oder zwei lokale Variablen

- und ein paar Defines

Das nehme ich dann, kopiere es und fertig ist die neue RIO-Synthese im offiziellen Release :)

Bei meiner Umsetzung hab ich mich oftmals an den Möglichkeiten des Phrasolator Programm gehalten, da man hier im Synth bereich genau die Sachen differenziert / explizit einstellen kann. Alle oben beschriebenen Parameter lassen sich sehr einfach in der K64 Applikation einstellen und macht vorallem damit am meisten Sinn. Die K64 ist noch nicht fertig und ich wollt eher daran weiterarbeiten.. alles andere würde mich nun um wochen arbeit zurückwerfen...

Bisher kann ich nur Sachen rauslesen, die alle gehen sollten (außer das Pedal/Hold) oder deren Zweck ich nicht kapiere (siehe Missverständnis Knacken <-> Envelope).

Auf jeden Fall bemühe ich mich, dass wir soweit übereinkommen, dass du den Chip mit deiner K64 benutzen kannst.

Viele Grüße,

AC

kII_OSC_test_070414.mp3

kII_OSC_test_070414.mp3

[Rio]

um es kurz zu fassen:

klar ist es ein billiger 8bit chip. Ich hab einfach das nervige knacken mit dem workaround umgangen, um mit dem chip auch mal was soundmäßig (oder auch mal für ne aufnahme/Fxs) was machen zu können ;) die meiste zeit arbeite ich meist eh nur im HOLD modus, um verzögerungen zu vermeiden und am ton zu arbeiten.

Das Workaround hält sich übrigends noch in grenzen. Ich hab am Wochenende mal das ganze mit Mastervolumen probiert. da kommen fast noch größere verzögerungen zu stande bei immernoch hörbaren knacksen.

Diese "VOlumenslides" habe ich ja für jeden einzelnen OSC gemacht und die sinken und steigen ja nur um die jeweiligen neue werte. Größte Verzögerung (worst case) entsteht beiVolumeslide von 0 bis 31 oder 31 bis 0. Ist der HOLD modus an, sind die Wege ziemlich gering oder gar keine vorhanden.

ein ADSR einbauen?.. na da kannst du ja selber nachrechnen wieviele Bytes dann gesendet werden müssen. Diese serielle Verbindung hat halt einfach nur seine Nachteile in bezug auf direkte Arbeit mit dem CHIP. ich würde den Chip auch nicht überbewerten.

Übrigends lade ich heutzutage alles über MIOSStudio rauf.. mit syx möchte und kann ich nix anfangen..

ungewollte "Ready" Phrase:

Wo und wann genau passiert das?

Auf welchem Kanal? Ist der Handtracker aktiv?

Ist der Garbage-Collecor aktiv?

ich glaub egal welcher channel. handtracker ist aus. Garbage-Collecor ist glaub ich an.

Naja, dazu kommt, dass dein Mod zusätzlich zu meinen alten auch noch neue bugs bekommen hat. Genau hierin sehe ich auch eines der größten Probleme, wenn du einen mod veröffentlichst: nämlich, dass alte Bugs weiterbestehen und neue Bugs hinzukommen:

1. Note-ON/OFF bug, harmonizer (s. oben)

2. und mir sind die Harmonischen in der OSCSynthese aufgefallen. Ich weiß nicht warum du da was geändert hast (oder ob das urspünglich mein Fehler war)

3. Und noch ein Wort zu dem von dir beschriebene Effekt deines Mods (dass es bei höheren Werten mit best. ENV laut zu krachen beginnt).

zu1: na kann man korrigieren.

zu2: kann ein fehler von mir bei der übernahme sein, oder war vorher in der alten verison so... war keine absicht! kann man auch korrigieren

zu3: tritt beim hold modus bis jetzt gar nicht auf..

und ja das kann eventuell schon durch die zu vielen ereignisse auftreten.. aber warum nur im hohen bereich? (unklar)

also, alle OSCs haben eine bestimmte Frequenz und dann machst du nur die Lautstärke an/aus... verstehe ich das richtig?

Kannst du das noch genauer beschreiben?

na nicht ganz:

ich hab halt meine 5 Soundkanäle. Die sind zum Anfang mute. es kann OSC1..5 gewählt werden, die Lautstärke (Hold-modus) eingestellt und ebenfalls die Frequenz per Tastatur für jeden OSC eingestellt werden. Das alles passiert in MIDI-CH 11..15. Midi-CH 16 ist abhängig welcher MOD eingestellt ist (ich hab im code den fälschlicherweise env_mod genannt. aber hat mit env nix zu tun) und im CH16 werden dann alle eingestimmten OSCs relative zur Tonhöhe gespielt.

MOD 1 bis 5 schaltet die OSCs zu. Desto weniger OSCs zugeschaltet sind desto schneller wird das workaround für jeden Channel verarbeitet. Beim HOLD Modus kann mit allen Kanälen ohne verzögerung gearbeitet werden.

Und wie gesagt der MOD 6 macht deine OSCSynthese und nichts anderes - ohne veränderungen! es könnten meinetwegen auch noch tausendandere modi im Ch 16 eingeführt werden.

und workaround für was? Für die "Knackser" am Anfang?

hab' ich auch nicht verstanden. Aber es würde bedeuten, dass die Velocity des Anschlags flöten geht.

warum sollten die verloren gehen? Es wird genau auf die Anschlags-Laustärke erhöht.

Ich meine, ist ja klar, dass es Bugs gibt, wo gibt's die nicht. Aber findest du das wirklich sinnvoll, zwei buggy Versionen rauszuhauen? Sollte man nicht lieber gemeinsam an einer richtig guten Version ohne Bugs arbeiten?

na so buggy ist die ja garnicht. Wie gesagt ich kann gut damit leben. aber mir ist immernoch nicht klar, wie denn eine fusion erfolgen sollte. Ich will mit dem knacksen nicht leben und du willst das zeitkritische nicht...

was soll ich dazu sagen. Mir ist auch noch nicht klar was du von allen anderen Anpassungen hälts.. ich habe das gefühl ich müsste dann überall kompromisse machen, und ob dann was besseres rauskommt? Anderseits würde eine komplett neue anpassung (CCs, neue Verfahren) meine alte applikation über bord werfen und eine komplette neuprogrammierung /anpassung verlangen .. wofür ich nicht die zeit oder lust habe. Die K64 würde mit der jetzigen K2 nicht laufen!

Was spricht denn konkret dagegen, das in einer _eigenen_ Funktion zu realisieren

das das für eine direkte arbeit mit den Parametern des Chip nicht in einer Applikation mit unterschiedlichen Anwendungsfällen gehen wird!

Ich sehe für die anpassung nur riesen aufwand und im schlimmsten Fall noch Verständigungsprobleme, was für den einen sinnvoll erscheint und für den anderen nicht.

Wer soll die Anpassung machen und ist diese soweit sinnvoll, wie würden die CCs abgestimmt werden - also sind dann auch alle Sachen so integriert, dass jeder zufrieden ist? ich sehe irgendwie nicht das Licht am Ende des Tunnels. Zumal ich auch wahrscheinlich in nächster Zeit andere Sachen machen muss und mir zeit und nerven dafür fehlen würden.

Ich hab keine konkrete Vorstellung für eine Lösung.

Mich würde auch mal interessieren, wer so noch mit dem SpeakJet rumhantiert.

[seppoman]

Hallo,

aus aktuellem Anlass zitiere ich mich mal selbst:

Ich würde wenn irgend möglich empfehlen, dieses Projekt nicht in mehrere Release-Stränge zu zerpflücken. Selbst wenn das gelegentlich Kompromisse bedingt, aber der SJ ist sowieso schon eher ein Seitenprojekt hier auf ucapps, und wenn sich Newbies dafür interessieren und dann mehrere verschiedene Software-Versionen zur Auswahl finden, dann ist das eher verwirrend als nützlich.

Um zu Euren Streitpunkten inhaltlich beizutragen, fehlt mir die reale Erfahrung mit dem SJ. Aus Eurer Diskussion bekomme ich allerdings den Eindruck, dass Eure Wünsche nicht soooo weit auseinander sind. Das Geschriebene lässt für mich nur zwei Interpretationen zu:

1. Ihr redet einfach etwas aneinander vorbei und solltet Euch mal auf ein Bier treffen.

oder 2. nimms mir nicht übel, Rio, aber es macht für mich einfach etwas den Eindruck, als wolltest Du nicht aus sachlichen sondern aus persönlichen Gründen auf Teufel-komm-raus eine eigene Version veröffentlichen. Was Du auf Deiner eigenen Kiste laufen hast, ist natürlich Deine Entscheidung. Für mich klingt die Diskussion trotzdem nicht so, als ob es nicht möglich wäre, die leichten Unterschiede in den Features durch irgendein Flag beim compilieren einstellen zu können. Für zukünftige SJ-Bauer wär´s auf jeden Fall besser so.

Nichts für ungut,

Seppoman

[Rio]

nimms mir nicht übel, Rio, aber es macht für mich einfach etwas den Eindruck, als wolltest Du nicht aus sachlichen sondern aus persönlichen Gründen auf Teufel-komm-raus eine eigene Version veröffentlichen

ne siehst du falsch, bin schon am überlegen ob ich gänzlich eine veröffentlichung insgesamt meinerseits lassen würde.. genau aus den oben beschriebenen gründen und das sich leute später nicht dran zweifeln und es kein streit gibt..

es sind einfach zu viele sachen unklar, wie denn eine "neue einheitliche" Applikation im gegensatz zur modifizierten Applikation mit allen Neuerungen aussehen würde und ob dies überhaupt mit allen Funktionen realisierbar wäre und wieviel arbeit jetzt dahinter steckt. Ich habe keine Alternative zu den fundamentalen Änderungen-> z.B. Workaround, welches zeitaufwendiger bei NOTE ON / OFF Funktionen sein kann, jedoch im HOLD modus nicht merklich ist. Das knacksen ist dagegen voll nervig.. ich habs ja ewig getestet und möchte damit einfach nicht arbeiten - fertig.

Ich habe versucht in meinem oberen Schreiben genau das zu beschreiben. Ich hab ja audiocommander ein letztes build des modifizierten K2 geschickt. Also von daher kann man nicht behaupten das ich unbedingt auf meinen sch.. bestehen will, sondern das er sich bitte alle änderungen mal anschaut und testet. es können ja auch alle änderungen der mod. Version auch über ein MidiKeyboard (mit CC-Controller) getestet werden...

Allein schon die Sache mit dem bei mir implemetierten Workaround und mit dem Ansatz mit den gestimmten OSCs zu spielen ist ein komplett anderer Ansatz (es sind ja noch weitere änderungen).. wie eine allgemeingültige Lösung nun aussehen könnte, ob alles übernommen werden kann und wer das im endeffekt umsetzen würde ist unklar..

man könnte natürlich alles möglichen Änderungen mit #defines versehen... aber ist hier Aufwand == Nutzen und ist das sinnvoll?

Mir fehlt hier einfach auch noch das Grundkonzept was von meinen Änderungen (CCs, Variablen, Funktionen) übernommen und was durch #defines getrennt werden sollte...

Z.B. es müsste bei jeden Kompromiss oder andersartiger Einarbeitung der CCs die Funktionen für das C64Keyboard ebenfalls neu überarbeitet werden... usw.

das sollte natürlich weitesgehend vermieden werden.

Zumal mir dafür einfach die Zeit fehlt...

[audiocommander]

Hallo Rio,

schnell ein kurzes Zwischen-Update:

ich habe mit Seppoman gechattet und ich glaube, ich sehe jetzt ein wenig klarer :)

Ich bin gerade ziemlich knapp mit meiner Zeit (Semesteranfang, viel Arbeit und eine neue Ausstellung...). Ich werde mich in einigen Tagen (spätestens in vier Wochen) mit einer kurzen Liste melden, welche Synthie-Funktionen ich in das Programm aufnehme. So wie es aussieht, sollten damit deine Ideen umzusetzen sein und der Programmier-Aufwand dafür scheint nicht sehr groß. :)

Mehr in Kürze!

Grüße,

Michael

[Rio]

jo hört sich gut an.

Ich bin gerade ziemlich knapp mit meiner Zeit.

ist bei mir genauso.. viel zu tun auf arbeit, kommende Umzüge etc. daher sind auch viele bedenken einer realisierung meinerseits.

Wenn ein abgestimmter Plan da ist, kann man viel eher Sachen gemeinsam umsetzen oder im vorab genau abschätzen, ob machbar oder nicht.. -> da sollte dann im vorfeld bevor was als Code realisiert wird der Plan gemacht werden und gegenseitig abgestimmt werden. Ich müsste zum Verständnis dazu Screenshots (mit beschreibung) der K64 machen damit du siehts, wie genau mit den Parametern (CCs) gearbeitet wird -> ich denk mal sowas wäre im Vorfeld notwendig.

Wie gesagt, falls alles zu konfus wird..., nicht weiter schlimm, dann würde ich eher von einer integration oder veröffentlichung meinerseits absehen. ...aber klar ne Einigung ist immer zu begrüßen.

Und hier hab ich gleich noch ein paar erklärungen zum Code:

1.

(m.a.W. es gibt in meinem Code kein MSA_Stop() in Verbindung mit OSCs)

upss.. viel mir eben noch auf.. ich meine auch eher das MSA_VOLUME, welches ja sonst im Vorfeld die Volumewerte der OSCs schluckt:

			// set Velocity
			if(channel != SJCH_PITCH) { 
				// set volume
				if( (evnt2 > 0) || ((evnt2 == 0) && (evnt1 == lastNoteDown[channel]))) {
					IIC_SPEAKJET_MSA_Volume(evnt2); 
				}
			}

darum übergehe ich den code für Channel 11-16:

			// set Velocity
			// RIO: except OSCs Channels!
			if(channel != SJCH_PITCH && channel < 11) {
				// set volume
				if( (evnt2 > 0) || ((evnt2 == 0) && (evnt1 == lastNoteDown[channel]))) {
					IIC_SPEAKJET_MSA_Volume(evnt2);
				}
			}

und speicher mir selbständig die alten Werte in osclevel[5] (array für alle 5 OSC Volumewerte.. -> z.B. wenn evnt2 = 0 wird, wird das Volume für den OSCs = 0 - also nix zu hören, beim Hold Modus wird eine aktuelle Anpassung des Volumes umgangen) 2. IIC_SPEAKJET_TransmitDigi2 hab ich eingeführt für eine schneller verarbeitung, da nur 2 digits berechnet werden müssen.. also zahlen von 0..99 bei den Volumeberechnungen, die bei loops schnell berechnet werden sollen. IIC_SPEAKJET_Transmit14bit (oder IIC_SPEAKJET_TransmitNumber) könnte schon bei zeitkritischen Ereignissen zu lange dauern. 3. ebenfalls werden geschwindigkeitsoptimierung durch folgendes gerüst ereicht, um die zeitintensiven IIC_SPEAKJET_TransmitStart(0) und IIC_SPEAKJET_TransmitStop() z.B. bei loops oder mehrfacher verarbeitung von Daten an den SpeakJet nicht immer wieder aufrufen zu müssen, was ja ebenfalls zeit kosten würde:

unsigned char proceed;
proceed = sj_stepseq.scpMode;

...
...
if (!proceed) {
  IIC_SPEAKJET_TransmitStart(0);
  IIC_SPEAKJET_SCP_Enter(0, SCP_CTRLTYPE_REGISTER);
}

...
...

if (!proceed) {
  IIC_SPEAKJET_SCP_Exit(0);
  IIC_SPEAKJET_TransmitStop();
}

4. Das lastNoteDown array ist für die speicherung der gestimmten OSCs Werte um in multiplay diesen Noten relativ zu verschieben. 5. beachte bitte folgende CCs:

	- additional midi CCs:

		SJCC_ENV_STATE			52			// toogle envelope state (0,1,2,3)
		SJCC_ENV_SLIDE			53			// toogle envelope slide mode (ON,OFF,REL)
		SJCC_ENV_MOD			54			// toogle poly mode (in channel 16)
														1: OSC1		active for OSCMultiPlay
														2: OSC12	active for OSCMultiPlay
														3: OSC123	active for OSCMultiPlay
														4: OSC1234	active for OSCMultiPlay
														5: OSC12345	active for OSCMultiPlay
														6: OSCSynthesis with all 5 OSC
																	Waveform change enabled

		SJCC_VOL_HOLD			55

		SJCC_ENV_SSTATE			62			// Set Slide values..look above for info
		SJCC_ENV_SSLIDE			63
		SJCC_ENV_SMOD			64

kurze Erklärung:

die CCs 52..54 aktivieren die Toggle-funktionen.

ok, bei SJCC_ENV_MOD, SJCC_ENV_SMOD hab ich mich in der namensgebung geirrt. Die müssten einfach SJCC_MOD und SJCC_SMOD heissen, da die nix mit dem ENV zu tun haben, sondern den Modus für Channel 16 bestimmen. 1..5 gibt an welche OSC zugeschaltet werden, 6 ist deine OSCSynthese.

SJCC_ENV_STATE - das wäre die auswahl wo der ENV zugeschaltet werden würde (0 = gar nicht oder 1 = OSC123 oder 2 = 45 oder 3 = 12345)

SJCC_ENV_SLIDE - das wäre die auswahl, ob der ENV entweder mit der OSC-Note schwingen soll, relativ zur OSC-Note in einer Freq. schwingen soll oder unabhängig davon mit Werten von 0..255 (sowie im Phraselator)).

SJCC_VOL_HOLD wichtig um Volumewerte unberücksichtigt beim Spielen von noten zu lassen!

CCs 62 .. 64 sind genau wie 52..54 nur das hier die Einstellungen direkt eingestellt werden können (also sogenannte Slide Funktionen von 0..127 z.B. für Rotary Encoder)

worüber sich dann auch ein kopf gemacht werden muss, wie alle Informationen dargestellt werden sollen, damit die Anzeige übersichtlich bleibt. Darum erscheint zum Beispiel der Harmonizer nur bei mir auf dem Bildschirm, wenn man ihn braucht oder aktiviert zur Laufzeit und verschwindet auf dem Display dann wieder. Beim Einstellen des SJCC_ENV_SLIDE wird auch nur für eine bestimmte Zeit per Message die Änderung dargestellt.. damit bleibt der Bildschirm noch übersichtlich. (die Anzeige ist für 2x16).