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.

danke, bin schon zurück 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. muss ich mir anschauen... 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. ..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. gruselig? mhh... um maximale Möglichkeiten in der Klangsynthese zu bieten, sollte alles getrennt einstellbar bleiben. ?? 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. 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. 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..

mhh... ich weiss das thema hatten wir hier irgendwo schon mal...aber kann mir wer sagen, wo ich die Kappen für die Rotary Encoder von TK's Midibox SID finde? Grüße Rio.

sehr schön...geht doch voran

MB SEQ V3.0 Applikation is released. A big thanx and respect to T.K. for his enormous finished work... !!! :)

M-Audio usb - midi products are useful and stable (use it since years)

like your Ain't.mp3 ;D yes and last picture is funny....cable master!

Yeaah!!! ;D PS: aber irgendwie hab ich durchs testen das meiste mir schon angeeignet :P

mhh... vielleicht doch. Wenns mit einer bestimmten Einstellung zusammenhängt, die bei den anderen Patches auch genutzt wird. Eventuell bestimmte Waveform, Channel, Filter...etc. schau mal wo es sich auswirkt. Du kannst ja auch die Einstellungen im Patch selber so weit alles verändern, mal schauen bei welcher ändernung es verschwindet...

hört sich komisch an... wenns ein effekt wäre dann wär es ein chorus. irgendwie verstimmt. - kann sein der SID hat n knacks... (was ich nicht hoffe) ??? überprüf mal sicherheitshalber alle lötstellen des SID Moduls.. PS: ach zu den Shift-Register... es sollte eigentlich egal sein ob die ungenutzen sich drauf befinden oder nicht.. Jedoch ist bei meiner SEQV3 tatsächlich der Fall, das die letzten beiden ungenutzten Shiftregister von 12, Probleme für die digitale Ein- und Ausgabe machen (Ich vermute mal, da ich alles sehr eng verbaut habe). Eigentlich dürfte sowas nicht passieren. Ich habe sie dann auch einfach runtergenommen. Ich glaube aber nicht, dass bei deiner einen DINX das der Fall ist und sich auf den SID auswirkt.

mhhh... Where should energy goes to? It's normal that 14V ->9V will warmup your regulator... and this part works only with higher incoming Voltage! if you are to scared, you should use a heat sink..., but i work 2 years constantly with my device and i've got never a problem...

? yes regulator will be warm (thats normal), but i don't think that this would be a reason, that your C64 PSU will blow away ;D