NRPNs zwingen DAW/rechner in die knie

huhu,

hab ein seltsames problem.
sobald ich versuche NRPNs per midi raus zu schicken fängt meine DAW stark an zu ruckeln und die cpu last schnellt hoch.
CCs und noten klappen wunderbar.

aber selbst wenn ich nur eine simple noten spur ausgeb und dann per maus an einem NRPN regler drehe (oder bei ableton per midiOX nen CC auf nen NRPN route) ruckelt die DAW und schafft es nicht mal mehr die paar noten tight auszugeben (versucht mit Live und fruity loops).

ist auch egal welches midi interface ich nehm. hab ein miditech usb interface, ein scope board, und usb midi von nem hardware synth versucht. immer das gleiche.
woran könnte das denn liegen? ist mir rätselhaft, denn CCs kann ich ohne ende rausgeben ohne probleme und so ein nrpn sind ja auch nur 3 MSGs mehr als ein cc...

das ganze unter winXP32.

gruß,
comboy
 
Wirklich mit NRPNs kann man eh nicht arbeiten, da sie nicht vernünftig zu editieren sind. Es bietet ja niemand einen Editor an, der die Kaskadierung in Grafik umsetzt, sodaß man einfach seine Kürvchen einzeichnet.

Richtig belasten tut es sie aber ansich nicht. Zumindest nicht bei mir (Logic 9, zB mit Andro, AMT8). Das kann an der AMT Technik liegen, lief schon in 6.XX und 8 ok ab. JEdenfalls lief das alles ohne großes Bremsen oder sowas. Es war halt nur aufzupassen, nicht zu viel anderes Zeug über den gleichen Port laufen zu lassen, weil bei MIDI gibt es eine klare Regel: Zu viel bedeutet, dass es Notenhänger gibt und das nicht durchkommt, was wichtig ist sondern was zufällig es schafft. Daher musst du immer so arbeiten, dass es grade ALLES läuft, das liegt aber an der verwendeten Technik.

Bei neueren Geräten ist der MIDI Controller auch schnell genug, bzw schneller als ältere.
 
Hallo, wie gibst Du denn die NRPNs ein?

Das Problem ist, dass NRPNs im Prinzip performant sind, wenn sie vernünftig eingesetzt werden.
NRPNs bestehen eigentlich immer aus einem oder zwei Adress-Wörtern und einem Datenwort. Es genügt die Addresse ein einziges Mal zu senden und danach nur noch die Daten. Erst wenn man an einem anderen Parameter drehen will, dann muss man auf die jeweils andere Adresse umstellen. Wenn man aber zwei (oder mehr) Parameter gleichzeitig ändern will, dann muss man andauernd die Adress-Wörter mit senden, und das erzeugt natuerlich einen riesen Daten-Overhead.

NRPNs sind also nicht wirklich geeignet, um in Echtzeit an vielen Parametern gleichzeitig kontinuierlich zu drehen. Dafür sind CCs definitiv besser geeignet.

Wenn man aber aber nur einmalig eindeutige Sprung Werte senden will, dann sind sie völlig ok.

Ein weiteres Problem könnte natürlich auch von Deinem Empfäger ausgehen. Wenn der die Daten Through-mäßig wieder rauspustet und die in den Sequencer wieder rein gehen, dann vervielfacht sich der Datenstrom natuerlich. (dazu muss man bei manchen Sequencern nicht mal im Record-Mode sein).

Florian
 
Moogulator schrieb:
Wirklich mit NRPNs kann man eh nicht arbeiten, da sie nicht vernünftig zu editieren sind. Es bietet ja niemand einen Editor an, der die Kaskadierung in Grafik umsetzt, sodaß man einfach seine Kürvchen einzeichnet.

Höhere Auflösung ist nur ein kleines Teilgebiet für NRPN-Anwendungen.

Hier scheint übrigens generell Begriffsverwirrung zu herrschen: NRPNs haben nichts mit Sysex und nicht zwingend was mit Erhöhung der Auflösung zu tun (man kann sie für letzteres aber verwenden), sondern bezeichnen CCs, die nicht im Standard enthalten sind. Für Sysex-Parameter gibt es keinen Standard, also auch keine RPNs und demzufolge auch keine NRPNs.
Der synthwiki-Eintrag https://www.sequencer.de/synth/index.php/NRPN dazu ist übrigens flsach. ;-)
Korrekt und ausführlicher erklärt, findet man das hier: http://www.philrees.co.uk/nrpnq.htm
 
Es steht nirgends, dass NRPNs SysEx wären.
Aber der sinnvollste Ansatz ist natürlich die Kaskadierung. Was aber stimmt, dass sie nicht vollständig ist. Das Wiki war mal dazu gedacht allgemein editiert zu werden und damit eben verbessert und korrigiert. Ist leider nicht. Steht aber frei ;-)
 
Moogulator schrieb:
Es steht nirgends, dass NRPNs SysEx wären.

Florians Antwort liest sich so (weil sie im Gegensatz zu CCs erwähnt werden).

Aber der sinnvollste Ansatz ist natürlich die Kaskadierung.

Interessant. Ich persönlich finde ja den Ansatz damit mehr/bestimmte Klangparameter steuern zu können am Sinnvollsten (vor allem, wenn es wie beim Waldorf Pulse mit der Möglichkeit eines CC-Dumps verbunden wird). Höhere Auflösung würde ich eher mit Sysex realisieren...performancetechnisch macht das so gut wie keinen Unterschied. Und wesentlich komplizierter als MSB/LSB-Kaskaden ist Sysex auch nicht wirklich ;-)
 
Moogulator schrieb:
Richtig belasten tut es sie aber ansich nicht. Zumindest nicht bei mir (Logic 9, zB mit Andro, AMT8). Das kann an der AMT Technik liegen, lief schon in 6.XX und 8 ok ab. JEdenfalls lief das alles ohne großes Bremsen oder sowas.

Lief auch frueher noch auf 'nem P200 der 'ne AWE32 angesteuert hat, wurde von Cakewalk noch ganz gut unterstuetzt...

@Comboy

Koennte wirklich am verwendeten MIDI-Interface liegen, hast wahrscheinlich 3 "Problemkinder", mit schlechten oder Windows eigenen Treibern erwischt. Koenntest hoechsten mal die "Leistung fuer Hintergrunddienste optimieren", wie das von Roland in der Anleitung zu ihren Audio/MIDI Geraeten empfohlen wird, auch wenn das bei mir nie was gebracht hat.
 
florian_anwander schrieb:
Hallo, wie gibst Du denn die NRPNs ein?
ich habs mal mit der fruity loops 8er demo versucht. die unterstützt NRPNs in der midi out controller oberfläche.
schickt dann allerdings auch bei jedem wertwechsel beide adress und datenwörter.

dann hab ich noch versucht in ableton live eine midi cc spur über midiYoke an midiOX zu schicken und das ganze von midiOX in gewünschte NRPNs zu wandeln.
Das Problem ist, dass NRPNs im Prinzip performant sind, wenn sie vernünftig eingesetzt werden.
NRPNs bestehen eigentlich immer aus einem oder zwei Adress-Wörtern und einem Datenwort. Es genügt die Addresse ein einziges Mal zu senden und danach nur noch die Daten. Erst wenn man an einem anderen Parameter drehen will, dann muss man auf die jeweils andere Adresse umstellen. Wenn man aber zwei (oder mehr) Parameter gleichzeitig ändern will, dann muss man andauernd die Adress-Wörter mit senden, und das erzeugt natuerlich einen riesen Daten-Overhead.

NRPNs sind also nicht wirklich geeignet, um in Echtzeit an vielen Parametern gleichzeitig kontinuierlich zu drehen. Dafür sind CCs definitiv besser geeignet.
ja das ist mir schon klar. und genau das versteh ich an der sache ja nicht...
es reicht bereits nix anderes als EINEN nrpn auszugeben und die DAW kommt total ins stottern.
also keinen synth nebenher, keine noten ausgabe, wirklich nur einen nrpn verlauf von nem poti.

geb ich dagegen 5 midi CCs paralell von ner fein aufgelösten automatisationsspur aus läuft alles butterweich. dabei ist das dann sogar ein midi commando mehr als ein nrpn. also sollte die bandbreite ausreichen.
Wenn man aber aber nur einmalig eindeutige Sprung Werte senden will, dann sind sie völlig ok.

Ein weiteres Problem könnte natürlich auch von Deinem Empfäger ausgehen. Wenn der die Daten Through-mäßig wieder rauspustet und die in den Sequencer wieder rein gehen, dann vervielfacht sich der Datenstrom natuerlich. (dazu muss man bei manchen Sequencern nicht mal im Record-Mode sein).
nope - tritt auch auf wenn ich gar kein midi gerät angeschlossen habe.
 
Summa schrieb:
Moogulator schrieb:
Richtig belasten tut es sie aber ansich nicht. Zumindest nicht bei mir (Logic 9, zB mit Andro, AMT8). Das kann an der AMT Technik liegen, lief schon in 6.XX und 8 ok ab. JEdenfalls lief das alles ohne großes Bremsen oder sowas.

Lief auch frueher noch auf 'nem P200 der 'ne AWE32 angesteuert hat, wurde von Cakewalk noch ganz gut unterstuetzt...

@Comboy

Koennte wirklich am verwendeten MIDI-Interface liegen, hast wahrscheinlich 3 "Problemkinder", mit schlechten oder Windows eigenen Treibern erwischt. Koenntest hoechsten mal die "Leistung fuer Hintergrunddienste optimieren", wie das von Roland in der Anleitung zu ihren Audio/MIDI Geraeten empfohlen wird, auch wenn das bei mir nie was gebracht hat.

jepp ich vermute langsam auch das es entweder an meinem seltsamen gigabyte motherboard liegt (das macht auch probleme wenn ich per usb mit nem prommer was flashen will). werd das ganze mal mit nem anderen rechner versuchen und eventuell noch ein anderesmidi interface (wobei ich es schon seeehr komisch fände das 3 midi interfaces alle den gleichen bug haben). habs mittlerweile auch mal unter vista64 versucht. gleiches verhalten.

aber generell zu den NRPNs stellt sich mir dann die frage wie automatisiert man denn dann einen hardware synth der mehr als 127 parameter hat, wenn keine DAW NRPNs als kurve zeichnen kann?

gruß,
comboy
 
comboy schrieb:
aber generell zu den NRPNs stellt sich mir dann die frage wie automatisiert man denn dann einen hardware synth der mehr als 127 parameter hat, wenn keine DAW NRPNs als kurve zeichnen kann?

NRPNs sind ja schon innerhalb der 127 CCs ;-)
Zur Frage: Parameter, die nicht per RPN oder NRPN CCs erreichbar sind, automatisiert man per SysEx. Da ist aber nix mit Kurven malen, sondern man braucht einen SysEx-fähigen MIDI-Controller, dessen Ausgabe man in der DAW aufzeichnet. So automatisiere ich z.B. den Microwave 1 mit der Remote SL.
 
marv42dp schrieb:
Moogulator schrieb:
..
Aber der sinnvollste Ansatz ist natürlich die Kaskadierung.

Interessant. Ich persönlich finde ja den Ansatz damit mehr/bestimmte Klangparameter steuern zu können am Sinnvollsten (vor allem, wenn es wie beim Waldorf Pulse mit der Möglichkeit eines CC-Dumps verbunden wird). Höhere Auflösung würde ich eher mit Sysex realisieren...performancetechnisch macht das so gut wie keinen Unterschied. Und wesentlich komplizierter als MSB/LSB-Kaskaden ist Sysex auch nicht wirklich ;-)


Adressierung und Kaskadieren um höhere Auflösung bzw. mehr Adressen ansprechen zu können.
eben mehr als 128 Parameter und Werte größer als 127. So war es gemeint. Was ist denn nun falsch an dem Wiki und was an meiner Angabe, ..

Editor und Co ist natürlich eine Frage der Hersteller und DAWs, und besser als SysEx, was idR weniger für Realtime genutzt wird. MAn kann bei sowas generell ja eine Vielzahl Probleme lösen. Noch immer muss man zB beim Andromeda die NRPNs immer einspielen. Versuch die mal grafisch zu editieren!! Das halte ich für ein Defizit. Fehlt halt in der DAW.
 
das problem beim aufnehmen von NRPNs ist doch aber das ich dann im grunde wieder auf einen parameter beschränkt bin.

nehm ich NRPNs von einem controller in ableton auf klappt das ja auch wunderbar bei einem parameter.
sinds 2 kommt er schon arg durcheinander, weil eben die address und daten bytes wild durcheinandergewufelt werden.
vermute ich jedenfalls. kommt dann nur noch murks raus.

mach ich das per mapping über midiOX wird trotz geruckel wenigstens jeweils der richtige parameter gesteuert und es geht nix verloren ;-)

spricht aber bei meinem ruckel problem auch eher für ein windows/treiber problem.
denn es gibt keine notenhänger und auch keine verlorenen msgs wie mir scheint. ist eher so als würde der midi fifo immer nur schubweise geleert.

da wäre dann sysex wirklich besser

comboy
 
Das mein ich ja grade. Das liegt daran, dass die Kaskadierung in DAWs damit nicht umgehen können, man kann es nicht einfach einzeichnen als 16384-Wertebereich. Das sollte aber.
 
marv42dp schrieb:
... den Ansatz damit mehr/bestimmte Klangparameter steuern zu können am Sinnvollsten (vor allem, wenn es wie beim Waldorf Pulse mit der Möglichkeit eines CC-Dumps verbunden wird).
Habe ich hier Waldorf Pulse und Sysex und CC-Dumps gelesen? :)
Mich würde interessieren wie Du genau mit dem Pulse arbeitest? Ich habe immer noch nicht mein Traumsetup gefunden/erstellt. Mein Ziel wäre folgende Kriterien zu erfüllen:

1. Programs/Patches zu speichern und später wiederzuladen sollte so einfach funktionieren wie bei Vsti's. Ich meine damit, irgendein Menü wählen oder irgendwo klicken, Namen eingeben, fertig.

2. Die Soundparameter sollte man über mehrere Editoren GLEICHZEITIG bearbeiten können. d.h. alle Lösungen die nur von einem Editor ausgehen, würden auch rausfallen. Dieses Kriterium bedeutet, dass zur Speicherung der Soundparameter auf jeden Fall der interne Editzustand von der Hardware/Pulse geholt werden muss, denn kein zweiter/dritter... Editor kennt ja die Einstellungen in den jeweiligen anderen Editoren.

3. Alles muss schnell gehen, damit man nicht gross mit dem Speichern beschäftigt ist, stattdessen viel herumschrauben kann, wenn was gefällt, kurz wo klicken, gleich weitermachen ohne den Flow zu zerstören. Da würde sich auch Autonaming mit Datum-Uhrzeit anbieten.
 
comboy schrieb:
das problem beim aufnehmen von NRPNs ist doch aber das ich dann im grunde wieder auf einen parameter beschränkt bin.

nehm ich NRPNs von einem controller in ableton auf klappt das ja auch wunderbar bei einem parameter.
sinds 2 kommt er schon arg durcheinander, weil eben die address und daten bytes wild durcheinandergewufelt werden.
vermute ich jedenfalls. kommt dann nur noch murks raus.

mach ich das per mapping über midiOX wird trotz geruckel wenigstens jeweils der richtige parameter gesteuert und es geht nix verloren ;-)

spricht aber bei meinem ruckel problem auch eher für ein windows/treiber problem.
denn es gibt keine notenhänger und auch keine verlorenen msgs wie mir scheint. ist eher so als würde der midi fifo immer nur schubweise geleert.
Hast Du bei diesen Tests, alle anderen Midi-Port inputs und outputs deaktiviert, auch in MIDI-OX, d.h. in allen Midi-Anwendungen, die parallel laufen? Ich würde versuchen mit einem Minimalsetup die Tests durchzuführen und zunächst dort das Problem zu lösen.

Und zur Beschränkung auf nur einen Parameter:

The fact that separate Controller pairs are designated for the NRPN number and the RPN number may suggest that a MIDI channel could have simultaneously a current NRPN and a current RPN. However, NRPNs and RPNs share a common mechanism for setting the parameter value. Therefore there is only one active parameter number per channel.
Das bedeutet man sollte pro Port 16 NRPN's, jeweils 1 NRPN pro midi channel, ohne Probleme senden können. Da MIDI-Yoke bis zu 16 virtuelle Ports unterstützt, könnte man im Maximalfall 16 (Ports) * 16 (Midi channels) = 256 NRPN Werte parallel, ohne Probleme, nur über MIDI-Yoke senden können, natürlich nur theoretisch, praktisch müsste man testen und ausprobieren. Wenn man noch andere zusätzliche Ports dazuzählt, lässt sich diese Zahl nochmal erweitern, das sollten aber erst mal genug parallele Signale sein, oder?
 
TonE schrieb:
marv42dp schrieb:
... den Ansatz damit mehr/bestimmte Klangparameter steuern zu können am Sinnvollsten (vor allem, wenn es wie beim Waldorf Pulse mit der Möglichkeit eines CC-Dumps verbunden wird).
Habe ich hier Waldorf Pulse und Sysex und CC-Dumps gelesen? :)
Mich würde interessieren wie Du genau mit dem Pulse arbeitest?

Ich benutze ein CC-Template für die Remote SLs. Ich könnte denen per Knopfdruck am Pulse den Sound als CC-Dump schicken, aber das mache ich nie...ich habe i.d.R. kein Problem mit Parametersprüngen.

Ich habe immer noch nicht mein Traumsetup gefunden/erstellt. Mein Ziel wäre folgende Kriterien zu erfüllen:

1. Programs/Patches zu speichern und später wiederzuladen sollte so einfach funktionieren wie bei Vsti's. Ich meine damit, irgendein Menü wählen oder irgendwo klicken, Namen eingeben, fertig.

Namen kann die Kiste ja nicht, daher bieten Editoren das i.d.R. auch nicht an. Prinzipiell sollte MIDIQuestXL aber das "VSTi"-Kriterium erfüllen. Wollte das immer mal testen, bin aber noch nicht dazu gekommen.

2. Die Soundparameter sollte man über mehrere Editoren GLEICHZEITIG bearbeiten können. d.h. alle Lösungen die nur von einem Editor ausgehen, würden auch rausfallen. Dieses Kriterium bedeutet, dass zur Speicherung der Soundparameter auf jeden Fall der interne Editzustand von der Hardware/Pulse geholt werden muss, denn kein zweiter/dritter... Editor kennt ja die Einstellungen in den jeweiligen anderen Editoren.

Die beste Lösung dafür ist ein Editor, der alles kann, was man braucht. ;-)
 
marv42dp schrieb:
Die beste Lösung dafür ist ein Editor, der alles kann, was man braucht. ;-)
Nein, das würde mein zweites Kriterium dann nicht mehr erfüllen. Im Endeffekt geht es darum, dass die einzelnen Editoren nicht davon ausgehen sollten, dass sie den internen Zustand in der Hardware kennen, sie müssten sie vor jeder Speicherung zum Beispiel neu überprüfen und die Werte entsprechend anpassen.

Nur als Beispiel: Stell Dir vor Du suchst Klänge im Synthesizer, z.B. im Pulse, nicht nur über einen Editor, sondern zusätzlich dazu noch mit einem
a) Wacom-Tablett, was 5 oder mehr Parameter gleichzeitig verändern kann
b) Wii-remote controller, was auch einige Parameter ändern kann.

Mit nur einer Editoroberfläche und nur zwei Händen, oder nur einem Mauspointer, könnte man NIE so schnell so viele Sounds ausprobieren. Für experimentelle Soundsuche gefällt mir diese Methode besonders. Beim Pulse kann man da z.B. sehr gut mit den vielen Modulationskombinationen herumspielen. Ganz schnell findet man dann verrückte Sounds... brutale Sounds... ziemlich viel Krach oder Megabass auf jeden Fall. :)

Dazu noch einige Effekte in Echtzeit hinzugemischt, und schon ist man im Soundhimmel. Am liebsten sowas wie Ebbe und Flut dahinter wäre genial. Aber direkt MIDI scheint das Gerät ja nicht zu unterstützen!?
 


Neueste Beiträge

News

Zurück
Oben