DSP Robotics Support

tulamide wrote:Martin refuses to work with 3.0.6

You know, old men can be so stubborn haha!
Let me see if I can make 3.0.6 versions of Randy and MVerb7.

It'd be interesting to see if that would enable me to make .dlls on my old machine that don't exhibit the jumping volume problem. Right now I can only use RandomOsc 4. The computer seems happy enough with 3.0.8.1, but can't generate useable dlls from Randy with either _8 or _6.

I made an interesting observation:

1. ASM code generated with FS 3.0.8.1 will run in FS 3.0.6, even if it contains post-3.0.6 extensons (as indicated by FS code color turning black).
2. This is true as long as you don't edit the code in FS 3.0.6: insert a blank line and it will break.

That explains why FS 3.0.6 users have not complained to me all these years.

Aah - well spotted, Martin!

That explains why I've had so few problems since I down-graded to 3.0.6 recently. Given how much I like tinkering with ASM and how long I'd used 3.0.8.1 for, it seemed an odd coincidence that I must never have used any of the newer opcodes. Mystery solved, I think!

@Martin

Phew! I can relax. I was starting to wonder if I wasn’t hearing your work as God intended (you). But at the same time I was puzzled that your stuff never fails to function, which I would definitely expect if it contained unsupported code.

Isn’t it odd though? My best guess is that when a schematic is created it’s the machine-level code behind the ASM that’s being run in 3.06; the displayed ASM code is actually a textual representation of historical interest. That would mean when you start to edit the text, the unseen code would be updated by the more restricted 3.06 compiler and thus break irreparably.

Fortunately I’ve never been tempted to mess with your ASM!

Cheers

Spogg