Rio

dann würde meine MBSID schon seit Jahren keinen Mucks mehr machen... und nirgendwo steht das du den Gleichrichter abbauen sollst..

hat ich mir schon fast gedacht, dass das der Appeggior auf der rechten seite ist... kann man irgendwie auch 2 getrennte Transponierung auf diese Art vornehmen? Grüße Rio.

Hi TK, wie hast du es in deinem 2. YouTube-SEQV3 Video geschafft, linke und rechte Seite des Keyboards seperat für das Transposing mehrere Tracks zu nutzen? Beste Grüße, Rio

und schon neuigkeiten?

jo, für mich ebenfalls grünes Licht... OK

Bitte nur die aktuelle Liste als letzten eintrag und erweitern. Sieht doch sonst kein schwein mehr durch ;) Hier der letzte Stand: (Bitte von jedem auf Richtigkeit prüfen) RIO: 36 x 863062 Drehknopf DK16-190V3 A.6/4,5 AT=14,5 schwarz soft-transparent rot TR-3925 Stefanho: 4 x 401840 RSAON11M9 4 x 76656 FK 12/16 Silber 8 x 861048 Drehknopf DK13N-164 8 x 401747 RK11K114 Drehpoti leonard: 26 x 863062 Drehknopf DK16-190V3 A.6/4.5 AT=14,5 schwarz soft-transparent rot TR-3925 13 x 401602 STEC16B03 Encoder 24-P/V-Typ Flachachse 6?/L=25mm/ohne Rastungen ljmarkus: 20 x 866001 Drehknopf DK-34-170 A.6/45 SLP: 20 x 863062 Drehknopf DK16-190V3 A.6/4,5 AT=14,5 schwarz soft-transparent rot TR-3925

i don't remember when it occurs, but i've mentioned it after a while, while i was editing. ..and then the twisted state is kept.

nicht vergessen, nicht irgendwelche, sondern die Transparent roten ;) RIO: 35 x 863062 Drehknopf DK16-190V3 A.6/4,5 AT=14,5 schwarz soft-transparent rot TR-3925 Stefanho: 4 x 401840 RSAON11M9 4 x 76656 FK 12/16 Silber 8 x 861048 Drehknopf DK13N-164 8 x 401747 RK11K114 Drehpoti leonard: 20 x 863062 Drehknopf DK16-190V3 A.6/4.5 AT=14,5 schwarz soft-transparent rot TR-3925 ljmarkus: 20 x 866001 Drehknopf DK-34-170 A.6/45

i'm not really sure, where i got a graphical error for LEDs, but i think it's so: i've chain1234 the channels and setup channels to 1/32 (maybe different speeds for every channel) but mostly fast.. and i use experimental "progressive" mode... step forward: 3 back: 2 (or some similar option) After a while one LED state is twisted at the end of track: On that step the note isn't shown on LCD, but LED is burning. if i press then the GP button - the note is shown on LCD, but LED isn't burning... LED and LCD visuals are twisted at this step. ...-> but it's not really worse.. cause could be a time critical behaviour..

tipp von suital: auf www.albs.de -> lagerliste -> Knobs Rotary und dann in die Liste schauen

also ich würde 30x die Waldorf dinger (die schwarz/roten, wie bei TK's MB SID) nehmen: ich denk mal das sind die richtigen, oder?: albs P/N Drehknopf 863062 DK16-190V3 A.6/4,5 AT=14,5 schwarz soft-transparent rot TR-3925 @markus: Läuft noch die bestellung? was würde das kosten? bitte gib nochmal dazu antwort... Grüße Rio.

shit

echt? find die gar nicht in der Produktpalette.. oder bin ich blind?

jo hört sich gut an. 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. 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).

mhh... ich weiss nicht. Also ich finde diese Rot-Schwarzen teile bei alps nicht.. ich meine diese, wie sie auf dem photo zu sehen sind: http://www.ucapps.de/midibox_sid/midibox_sid_cs2.jpg

another link: http://hearingvoices.com/news/?p=144

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...

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: ich glaub egal welcher channel. handtracker ist aus. Garbage-Collecor ist glaub ich an. 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) 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. warum sollten die verloren gehen? Es wird genau auf die Anschlags-Laustärke erhöht. 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! 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.

compilieren ging jetzt (musste noch alle ht. im LCD Tick deaktivieren), aber.. mit welchem CC kann man den Envelope zuschalten/ausschalten? hab bisher nichts gefunden.. 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.. 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)

ok.. OSCSynthesis with Sync? i'll check it out ... can you please record a mp3 from playing some notes with one of that OSCs without envelope activated. I wanna listen whether it is noiseless..

mhh... can you record an mp3 from playing with different notes on 1 or more oscs.. without a envelope activated. I'll check out this "click noise".

mhhh.. no sonar pings... i've done a connection test... wasn't a problem...but the speakjet try talking in high pitched values...something miiaaoooo or muuuu.... hhhheeeeyyy.... but i've used the compiled KII_AIN_ENABLED = 1 mode..., because the other settings doesn't compiles.. maybe that was the problem.. i don't know.. i've upload my k2mod app. again and all works fine again.. so it isn't definitly the evil bug you describe... i'll test the new download version at evening again.

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 ;) ja ich hab schon gesehn das du einige sachen komplett neu strukturiert hast... Best grüße Rio.

ok i test it again... mhh... i mean of course that: // application defines #define KII_AIN_ENABLED 1 // if AIN (sensorMatrix) enabled, default: 0 and i couldn't compiled the project.. if this is 0 to 1) what is that sync stuff? to 2b) it's normal that the speakjet talks some high pitched or gliding vocals again and again?? don't understand...

1. Lässt sich leider nicht für die anderen Einstellungen (z.B. AIN = 0) compilieren.. 2. Nach Raufladen der funktionierenden Einstellung (AIN = 1, SYNC = 1) wird die READY Phrase durch two, one ersetzt... (na das hab ich mal gleich per phraselator wieder zurückgesetzt - sollte aber auch in der Applikation deakt. werden können) und es kommen dann komische laute im ziemlich hoher Tonhöhe, in gleichmäßigen zeitlichen Intervallen oder zufällig. sobald ich irgendeinen Channel anspiele werden die Laute auch wiedergegeben... Also ich konnte bisjetzt noch nichts damit anfangen. 3. Ich finde (das ist aber meine subjektive Meinung und nicht so vordergründig) die Darstellung am Display (216) nicht grad so übersichtlich...zummal mir die bezeichnungen auch fremd sind.