From the original SynthMaker forum (2004–2014), with its members’ names and dates.
mwvdlee ·
I've already reported some things here: [old link]
From what I've tested, it seems like the SM2 MIDI inputs are (semi-)randomly skipping notes. I'm inputting from a digital MIDI instruments, and some of the MIDI notes played on the hardware don't seem to be getting into SM2.
I've stripped down the project which worked fine (in this aspect) in SM1.7, to where it was just taking in plain MIDI notes and playing some basic samples without any effects, interpolation or even sample rate correction and it still managed to skip MIDI notes. The entire GUI was deleted except for the bare minimal parts I needed to get visual feedback on what was happenning internally. I don't know what more to strip without losing either sound or visual.
I've tested both MIDI>Poly and MIDI>Voices>Poly (tested all 32 possible boolean input combinations) paths, and they both produce the same skipping. Also tried the M>V>P standard module with the same results.
Here are some of the symptoms:
[*]Sometimes it's a single skipped note, sometimes it's a couple of notes in a row (within part of a second).
[*]The note-skipping seems to be linked to the green thread somehow, in that whenever it skips a couple of notes in a row, the GUI seems to stop refreshing too for the same period of time. I'm unable to visually see this for single-note skips.
[*]It also seems to skip more notes when playing multiple notes at the same time or in very fast sequence.
[*]The amount of skipping seems to change with what part of the schematic is visible on screen.
It's kinda hard to make a demonstration of this without giving away my schematic, but when people start using SM2 with actual MIDI hardware, I think it won't take long; I can play certain sequences that trigger this skipping within a few seconds.
This worked just fine, unchanged, in SM1.7, so it's a bug introduced in SM2.
MichaelBenjamin ·
that sounds pretty wierd, i havent encountered this yet.
maybe since redrawings use much more cpu (should be less), and it depends on what you see, maybe the green thread gets overloaded? not much of an idea else.
infuzion ·
MichaelBenjamin wrote: that sounds pretty wierd, i havent encountered this yet.
maybe since redrawings use much more cpu (should be less), and it depends on what you see, maybe the green thread gets overloaded? not much of an idea else.
Perhaps...
But really, all bug reports need atleast an OSM sent to support @ synthmaker, & helps to attach an OSM on the forum post for others to test. Also helps to know the CPU & computer specs when dealing with possible errors like this.
Tzarls ·
Does it skip notes it you just connect a midi in to a midi out (a pass-thru thing)?
mwvdlee ·
infuzion wrote: But really, all bug reports need atleast an OSM sent to support @ synthmaker, & helps to attach an OSM on the forum post for others to test.
Bug reports should not require customers to send in their copyrighted work.
I'll try to build a demo which does not contain any significant code, but the current description should be enough for OutSim to start looking; they know what they changed so they might have a good idea of what might have caused this.
Trying to make reproductions of bugs takes a lot of time, time I prefer to spend fixing my own bugs or just doing stuff I actually enjoy, and, quite frankly, I'm a little pissed off with waiting this long and paying for SM2 update, then finding it broken in one of the most significant areas.
infuzion wrote: Also helps to know the CPU & computer specs when dealing with possible errors like this.
@MichaelBenjamin. IMHO, MIDI I/O should be in the high-priority audio thread, not the normal-priority green thread. AFAIK, MIDI I/O _is_ (or "was"?) in the audio thread.
@Tzarls; I don't have any hardware to use the MIDI out signal, so I have no way of checking this.
Tzarls ·
You can export you OSM as VSTi. Then load it in your DAW, insert a track cointaining some MIDI events and route it to the VSTi. Route the MIDI events coming out of the VSTi to go into another track and record those notes. 🙂
mwvdlee ·
Tzarls wrote: You can export you OSM as VSTi. Then load it in your DAW, insert a track cointaining some MIDI events and route it to the VSTi. Route the MIDI events coming out of the VSTi to go into another track and record those notes. 🙂
I don't use any DAW 🙂
Basically I use VSTIHost as I'm currently only working on either standalone .exe or instruments meant for real-time playing.
I don't know of any good, free, DAW's, so if you can direct me to one that is suitable for testing this issue...
attic ·
I'm am also having these problems and in the same situation in giving away an osm as I have a year into it and cant afford to let the idea out yet. The midi triggering seems to be the issue it is causing intermittent bursts of sound from my sample playback engine and in such away as to risk any speakers that are used for bug testing. I'm in windows 7 64bit running on a Motu 2408mk3 midi is coming from a Korg M3 on the usb connection. This problem doesn't seem to exist in trogluddites sk sampler Fun with Burps that has some similarities to my project. My project also has similarities to the wave player osm that I posted at the bottom. It doesn't seem to have the same problems but it also doesn't have adsr and other things in it that my project does.
mwvdlee ·
The audio burst may be caused by MIDI too; maybe MIDI notes are just queued and when it doesn't take in notes for a fraction of a second, any notes played in that time are taken in all at once after that fraction of a second. I haven't noticed this myself, but perhaps it's what caused the "popping" sounds I heard.
attic ·
maybe MIDI notes are just queued and when it doesn't take in notes for a fraction of a second, any notes played in that time are taken in all at once after that fraction of a second
The way you state it is about as close to what I'm experiencing as could described. The bursts are intermittent, If I play a fast run of keys it will make a burst of distorted noise about 20 percent of the time. Usually one long burst, the other notes come out clear but then the distortion hits and it red-lines the meters for a second or two, also I get clicks and pops at key press time depending on adsr type or setting.
MichaelBenjamin ·
do you use an adsr primitive? if yes maybe try to exchange with another adsr.
also if you got midi-midi in over a pci card (not usb midi in) you could try that.
attic ·
Update so the bursts of distortion are gone something in the adsr's no clue what and it doesn't matter what adsr is in there it does it for all of them. Now the thing is without an adsr in the project I'm down to just the clicks and pops on triggering a sample. The loud pops happen between 1 and 8 key press's depends.
I don't know of any good, free, DAW's, so if you can direct me to one that is suitable for testing this issue.
Reaper its not free but it will run forever without any functionality gone you just have to wait for a five second countdown before using it. If your not using Reaper you should try it.
Edit .. After more testing and loading many variety of sample players it comes to this. Anything that uses midi to trigger
a sample on a Motu 2408mk3 Firewire is not working at least on Windows 7 64. This happens even if you do not use external midi to trigger but trigger from a button from within Synthmaker tested on two different Motu interfaces and two separate computers and the same results clicks at sample trigger.
Iman ·
Same here, Skipping note occurs in my exported exe and also inside SM environment.
Sometimes you cannot set voice number less than 8, I cannot play with 2,3,4,5 voices in some presets but when i select another preset or set voice more than 8 it starts receiving MIDI. very strange and totally random!
I think there is something wrong with new Enhanced "M to V" primitive.
mwvdlee ·
Iman wrote: Same here, Skipping note occurs in my exported exe and also inside SM environment.
Sometimes you cannot set voice number less than 8, I cannot play with 2,3,4,5 voices in some presets but when i select another preset or set voice more than 8 it starts receiving MIDI. very strange and totally random!
I think there is something wrong with new Enhanced "M to V" primitive.
It happens with the "MIDI to Poly" primitive too. Probably something shared by both.
I get the skipping voices even though I have it set to 128 voices (I only ever get to 40 or so).
attic ·
For those of you who may be having clicks on sample trigger. In SM2 there are changes to the way the stages work in the SM2 audio code so that the delays will work correctly.
This means that any Code Component that uses the Stage() keywords would need to be recompiled. SynthMaker only recompiles Code Component code if the code changes. This makes loading and saving much faster. It just so happens that the change will require some code components to be recompiled.
In your schematic there may be a delay and in that there are a few code components that use stages.
I'm not certain but it may be that all Code Components need to be recompiled, not just the ones that use Stages. The workaround is to go into code components that use stages and make some small change (add a blank line say) then click away to make them recompile. Just to be safe and banish the clicks permanently you may want to do this to all Code components.
I don't know if this will have any bearing on the midi note issue itself but it is worth a try and it did solve the problem I was having with clicks and pops on sample triggering. Let me know if this helps.
mwvdlee ·
attic wrote: This means that any Code Component that uses the Stage() keywords would need to be recompiled. SynthMaker only recompiles Code Component code if the code changes. This makes loading and saving much faster. It just so happens that the change will require some code components to be recompiled.
Like probably most people, I have a large number of separate projects, each of which has more separate code components all over the place than I can possibly remember. Is there a better way of forcing recompilation? Seems to me SM should check if a schematic comes from the same version of SM and force recompilation after loading if it doesn't.
trogluddite ·
Which begs the question - are there any legacy SM primitives which this might affect?
Things like 'R&D' primitives particularly may not have been fully checked for back compatability - already I've seen the example of old forum posts containing code modules that are not compiled at all (ASM text output is empty) until a compile is forced.
The issue with stage(1) posted elsewhere also makes me think - why was a 'faulty' schematic allowed to be exported? Surely there should have at least been some kind of warning (like the way invalid feedback links are highlighted) - not just a crashing export with not even an error code to report.
I wonder what sort of testing OutSim did on this - seems to me that they assumed that because FlowStone users aren't complaining, that SM2 would be OK too - but FlowStone has no legacy of existing users with old schematics requiring back-compatability. Surely there are enough example .osm's on the forum that they could easily have checked?
dutchound ·
I am having MIDI errors too. Certainly, any Midi generated inside the program, loses data ALOT! so if you play allegro, like 2-3 notes per second, then on a laptop you can expect to lose about 20 percent of your Midi notes. In effect this means that the internal Midi-out module is very buggy, bordering on unusable, because you cant play music through it, even less if you want to turn a knob at the same time. It seems that the "M" midi line is as reliable as the green lines because M is actually a green line in disguise... perhaps it's ok when the incoming midi ticks are generated by an external program, so that each midi event actually is translated into the stream lines?
which leads to the question... perhaps it would be possible to generate an external tick by using midi signals? if you had a midi event happening every 5 ms, it could produce a stable tick at 200Hz?
I know the developer has good intentions for this program... Cubase, Native, Cakewalk, ableton, would never accept the constant errors in one of their products, it needs a hotfix ASAP, and i think i have to get the UK magazines to write something about it's major bug issue in their pages because it's unfair to make a jolly coder pay money for it and ignore his lost work and pleas for a non buggy program. it's not version 2, it's alpha 0.095. why pay 200 euros for a product and then go "oh no the M lines have program errors since 1998, i will have to find a C++ solution" there has to be a hotfix ASAP for the paying developers that are tacken for a ride by SM's clock errors, prior to SM6.
attic ·
@dutchound My earlier posts on this thread have been cleared up. The recompile script thing fixed my issue and is no longer an issue in the new SM version. The Motu card problems also where fixed with the script recompile and many other Motu related problems are gone as of the new Motu 2012 drivers.
To offer what little help I can.. as I understand your frustration. One thing to look at is if you have many array reads happening this can slow the midi thread triggers. Definitely read Trogluddites Trigger Tutorials as there is some info in there that might help. You could of course post an .osm for the rest of us to look at for comparison across other machines. I hear where your coming from and I hope you can find a solution. I do tend to agree that the SM midi system could use some work.
dutchound ·
Thanks Attic for the advice, Yes 20 green lines to define a pattern totally caused the .osm to fall on its face... and that was for the most basic sequencer possible, or arrays, no green data reading and writing, just idle green lines being read into blue lines. i thought idle green lines were OK!
Here is a demo midi module, it just sends a counter through to make notes in the midi output. even this simple counter sequencer isnt reliable enough to make a VSTI using midi, you still would have to ditch SM and revert to C++ to make it reliable/sellable/playabe. Imagine how unstable this midi module is as soon as you put 5-10 gui elements, and a single array to hold and save your patterns with make it completely haywire!
I dont know if the "Midi-in" is equally unstable, perhaps it runs on ticks from the midi controller, (else it must be unstable too) and if it does, also the "midi-output" module could be set to trigger accurately from audio card derived ticks. The midi in SM must not be unusable for a 200 euro enterprise license. in fact all of synthmaker should clearly be working on hopped stream lines, the MIDI should not be dropping, neither the green lines, if they can get their tick from hopped audio rate.
stw ·
This isn't a bug. It's more of an annoying condition which is caused by the internal SM event handling.
The way you're using outgoing midi events can't work and probably never was intended to. But i've to admit this can be very confusing and doesn't make sense at all.
Whenever you change from streaming sample accurate (blue-mono/white poly) levels into green windows timed trigger levels you get unstable and data skipping results. So this is only suitable for graphic or other timing uncritical operations. "Reliable" midi event triggering only works if you stay at the midi level which is feed by incoming midi triggers. That means you can tweak incoming midi data and send it to the midi out maintaing its own triggers but you can't use SM to create new time stable midi triggers.
I guess there some threads in the forum which already adress these issues.
dutchound ·
stw wrote: This isn't a bug
it's an intentional function within synthhmaker to produce arrythmic and atonal music incase the planet is hologrammed into another unverse by a black hole, where time is irregular, so the only surviving program in the universe would be synthmaker's green lines, which would self replicate into new life-forms?
If the incoming midi ticks can be tethered to a events from outside the "green zone" there is no reason why the green and midi signals could not be tethered also to a master sync that runs of universe-time.
they should include a note with the midi output modules to say "these modules skip notes, you cant use them for commercial work" to avoid dissapointing the people that purchase SM...
EDIT- i just had a look at this again, i took out all the graphics components and just ran the midi... at 3 4 beats per second, here is the result... it should read 022446688 et... the following is a measure of accuracy on a workstation at 200bpm midi performance: and that's without even playing chords!
0
0
2
2
4
4
6
6
10
10
10
10
12
12
14
14
16
16
18
18... where did numbers 20. .. to 4 go?... there wasnt actuaally one sequence of 16 notes that played correctly!!!
6
6
6
6
10
10
10
10
12
12
14
14
16
16
18
18
22
22
26
26
28
28
32
32
2
2
4
4
10
10
14
14
14
14
18
18
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker