SM2 MIDI input skipping notes

[mwvdlee]

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]

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!

Code: Select all

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