I will try to add an audio example later. From what I hear, sometimes the midi messages go silent for a moment and after a while more delayed messages are played to keep up.
Ok. Here some short example how it going at my place. Sequence going from ableton by midi (not virtual cable) without any clock only midi notes. I noticed when i don't touching any knob its better but when some interface with info popups midi going weird. I've tried to disable graphics card but it didn't change anything. Maybe there is some problem with my hardware i dont know but when i sequencing samplers and some sytnhs or external vst this is not a problem only standard jitter.
when I use very short duration notes .. using the G2 ClkGen module as a trigger, and when in Wren I use EnvArRtrig set to N(ormal) mode it misses a lot of notes.
When I set the envelopes to H(old) mode I can hear that it does not actually miss any notes (for as far as I can hear it high speeds .. ) .. but it could be that the note-offs are sounding then instead (meaning that note-ons get fukt by a quikly following note-off).
Or it could be that the envelopes do not work properly with very short notes .. hmm .. nope that works fine .. so it must be MIDI indeed overwriting the ons with offs.
Will investigate this further .. interesting :lol:
Hmm .. things improve when the patch needs more CPU .. funny.
Hmm .. things improve when the patch needs more CPU .. funny.
of course .. note on and the later off end up in the same sample frame (which for a light patch get executed pretty quikly) so the off will almost immediately cancel the on ..
It needs a timer to determine the note duration .. the note on can then be processed immediately I think, and it sets a time stamp .. and then when a note off comes in a duration can be calculated .. which then gets decremented in the audio thread .. depending on sample rate .. and when < 0 only then the note off must be executed (and the off velocity be set).
Just implemented this on the single midi note in thingie, and things go way better .. will tinker some more though .. about what should happen with the note-on .. it is still a bit jittery.
Edit: yup, needs more work
Edit2: Made the module run at audio rate instead of control rate. With a buffer size of 256 it's sollid here & now with 16th notes @ 240 BPM .. thats almost a tone in itself then Still would be nice if it would work for larger buffer sizes too (for a buffer size of 2048 frames it's stable now upto 90 BPM or so .. which also means that a buffer of 512 would prolly still work ok too for the rate mentioned before), working a queues now. Anyways .. getting somewhere
there is a little jitter beteen left and right channels .. recorded this with the same patch as before except that I now used N(ormal) mode and not H(old) for the envelopes and added a little phase warping to the osc's that otherwise still are sines .. and a littl ebit if 3rd harmonic distortion .. so that should nit fuck the timing.
Buffer size was set to 512 sample rate of 48k .. so there is about 11 ms of audio in the buffers .. and so expecting a max jitter of about 11 ms too .. it seems less ... dunno .. and I ran this on a debug verson of Wren (which performs worse than the release version).
Edit: BPM starts at 90 .. then 120, 180 and 240. 1/16 notes.
Edit2: tried some quue tricks .. but that only made it worse.
Edit3: still need to apply the changes to the multi note in thingies and test that, somewhere next week I guess.
Found another bottleneck and solved that, midi code was posting messages to the GUI thread, bypassed that, injecting MIDI directly from the driver into the synth now .. for real-time and note messages only sofar .. but will add everything that way except sysex.
It does not seem to depend on the weather anymore :-)
Fixes for MIDI modules. MIDI was not really dropping notes, but note-offs could follow immediately after note-ons, so a trigger out did not get generated. Changed the timing, such that the actual note duration is being tracked now. Another issue was that the MIDI modules were not fast enough, so changed their processing to be at audio rates. The third issue was that the low level MIDI code was posting messages to the GUI thread to signal incoming data. This was changed to let the MIDI driver inject MIDI messages directly into audio thread. This also greatly reduced the sensitivity to GUI events happening.
Ran some tests on this and on my laptop with an ASIO buffer size of 256 the MIDI modules can now handle 1/16 notes at rates of 240 BPM. Audio buffer size matters still for MIDI timing accuracy, as a note-on event is not synced with the audio thread, only the duration is being calculated in samples now – so there still is note onset jitter, but that's a couple of milli seconds at most with the settings mentioned before.
[...]a note-on event is not synced with the audio thread, only the duration is being calculated in samples now – so there still is note onset jitter[...]
Ran some thought and code experiments to try to better up the note onset jitter, but this can only be fixed by introducing extra audio latency, as the note-ons will happen in a part of the audio buffering that is alread under control of the audo card .. I'd have to delay the audio for an extra buffer frame .. so .. there is a trade-off there .. jitter vs longer but predictable latency ... not really wanting to add extra audio latency now .. so ... for reasonable real time midi performance the bufer sizes will just have to be set low.
For now at least .. I may add an extra (configurable) audio delay at some stage.
The good news is that I was able to remove two days worth of experimental code in about 10 minutes
Also rock solid midi clock i think would be a strong point of wren. Most of the software have some nasty jitter. And i have a question. Would it be hard to implement gpu rendering of interface with vector graphics ? You said You Didn't have "vectors" somewhere. But if you had, it would be too time-consuming to implement ? How many elements need to be converted ? Of course, if you consider such a big change.
[...] But if you had, it would be too time-consuming to implement ? How many elements need to be converted ? Of course, if you consider such a big change.
Yeah, quite some work .. I would have to recode the user interface .. and also would need a new way to design modules ... I'm considering this every now and then .. but as of yet have not thought up a good way to do it.
So anyway, it is not just the images.
Ideally I see it as two separate programs, a sound engine and a control panel program, the latter maybe even being a web browser :shock: .. anyway, such would make it portable to other OSes too, or easier to make it portable at least.
Yes. Wren with some direct acces to dropbox or something for patches would be interesting. But too keep up compatibility with pletora of browsers and all that rubbish i think its a big pain and also no asio unfortunately so far. But gpu rendering even with same ui that would be a big change. Fluid interface and more resources from cpu for patch. I realize it's a lot of work considering how long it took Ableton to implement. But it was always funny for me how such a gpu beasts sitting idle at background doing nothing. Another architecture and latency but still funny there isn't offline renders for audio on gpus.
I've just posted a new version (2020-09-09) on my web site.
It is a bit experimental still I guess, the main feature is polyphony, and I've tested this for a month, or two maybe with a handful of patches and several old ones, so it may be reasonably stable.
For mono patches there is some extra overhead unfortunately, but in poly patches it is more efficient than patching the same thing out a couple of times.
Most modules are polyphonic, but for some it did not seem to make much sense (like reverbs), or I thought there to be too much overhead when polyphonizing them.
I've made a new tab on the module selector, Poly, for some polyphony specific modules - like a splitter from poly to multiple mono channels, a merger doing the reverse thing, a summer summing poly channels, a shifter for bringing a signal from one channel to another, a selector to select a specific channel (and a multi version of it, doing the same for up to eight signals), a status module which outputs the channel, a poly view module with a VU meter for each channel.
I would still like to have the ability to select parts of a patch to be monophonic, but I've not found a way acceptable to me for that, so in the source code you may find some hints for what I've tried sofar but in the program it has all been disabled (it was not working anyway). I did not like the idea of mono cables (as some synths have them), I did like the Clavia idea of having a mono section (for FX), but would prefer to have it a bit more flexible than that, anyway, that's a future thing, if at all.
I've also made a new PolyMidNoteIn module, a polyphonic version of the MidiNoteIn module, which for polyphonic patches is meant to replace the paraphonic Mid8NoteIn and MidiMultiNoteIn modules, it should offer the same functionality as those two but in a more transparent manner.
The existing delay based modules are kept monophonic mostly, in that they use a single shared delay line, but some can have a per-voice modulatable tap point, so the output can be poly even when the input is being summed over all voices. I've made a new DelayPoly module which is fully poly. I've tried to update the help stuff to give some information about all this, but I probably forgot some details.
Undid the 'smart' note processing for lower latency introduced in a previous version - it was not working properly .. a note would hold as long as it had been pressed .. or something like that .. strange stuff that I had not noticed because I had been testing with AD envelopes in trigger instead of in hold mode.
Then a couple of other changes you can read about at : https://bluehell.nl/wren/#changes - most interesting probably the ability to set selected modules into forced mono mode.
oh, and the ugly visual feedback on this can be turned off in the settings screen (F3).
As of 2021-04-03 I've made a pre-release version available for download, this is a 64 bit version only and I will try to keep it in sync with what I have currently running for the noodle radio channel - but - it will have an invalid version number, and you may want to generate your own help files for it (from the settings page).
There is a download link in the downloads section for it.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
Forum index » Instruments and Equipment » WREN
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
of course .. note on and the later off end up in the same sample frame (which for a light patch get executed pretty quikly) so the off will almost immediately cancel the on ..
Still would be nice if it would work for larger buffer sizes too (for a buffer size of 2048 frames it's stable now upto 90 BPM or so .. which also means that a buffer of 512 would prolly still work ok too for the rate mentioned before), working a queues now. Anyways .. getting somewhere 
. Nice.
