Hi Paul, in fact is what I’m doing (I’m testing), 3 x 8-frame intervals. It will be largely enough, attempting 3 x 16-frame. At the moment, 3x8-frame, “F3 performance” indicates around 0.3~0.8 (I’m using PC Windows 10, 2019 technology Intel Core i9-9900KF 8-core/16-thread CPU @ 4.5GHz overclocked, watercooled). GPU is NVidia RTX 2080 (8GB), displaying 1080p @ 60Hz (the limits of the screen).
Of course you’re right! I’ll consider this tip! Thank you. While audio processors aren’t entirely implemented (all 6 fully operators, and additional section such LFO/Pitch envelope etc), I’m in blind mode!
Mouse operations (for touchscreen) are active - in general - by OnButton() events only, such OSD pull-down menu, or Preferences screen (clickable radio-buttons / checkboxes / simple “LEARN” button + two arrows/triangles as “previous” / “next”…
Important sections (not under process() by .setDivision) also are guarded by a if() on unique bool variable! As example, if (LClick) {… for a left-mouse click.
It may be useful on certain platforms (such laptops) who are using a “limited” screen resolution - less than 1080p, when the user can’t see the DX7 LCD display (eg while editing synth parameters, all of them on display)…
When the mouse cursor is hovering COARSE, FINE or DETUNE potentiometer (top of any OPerator section), also the effective ratio (or fixed frequency) is displayed as a second tooltip line, exactly like this (1080p / zoom @ 100%):
Any control having its state LED or dedicated mini-display (like OP ON/OFF switch, OP MODE, OP L. CURVE, OP R. CURVE, LFO KEY SYNC, OSC KEY SYNC, and LFO WAVEFORM) doesn’t have tooltip.
Custom tooltips concern potentiometers only, from OP1 section to rightmost part of the module. Input and output jacks are using default VCV Rack tooltips (can’t be disabled).
May be enabled from Preferences screen (by default - or after a module reset, potentiometers tooltips are disabled).
Some global settings no more return to factory defaults on module reset (Ctrl+I / Command+I, or Initialize command from contextual menu): concern LCD/OLED emulation (from contextual menu), and these Preferences : Mod. key (future shortcut key for modulations), Pot. tooltips, Genuine 12-bit DAC emulation (not available at the moment, so this setting says grayed) and the operator output behaviors.
The module is ready for polyphony (input and output jacks, SIMD operations for poly voltages).
FIXED broken SysEx import (due to change type of variables! reverted back, fixed/OK).
(please always see lastest post in this topic, below, for package download links - Thanks!)
Tuesday (24th) daily blog… In development & testing phase…
Unexpected update (Feb 24th - 10:30AM GMT+1) due to broken SysEx import!
All packages are updated (Feb 24th - 10:30AM GMT+1) on GitHub.
Number of polyphonic channels is always the minimum regardling these connected input jacks: mandatory V/OCT and GATE, optional VEL. (velocity), optional AFT. (aftertouch), and optional RETRIG. (retriggers) input jacks. Please notice both optional PW (pitchbend wheel) & MW (modulation wheel) are “monophonic”, by the way, actions on them during play will affect every polyphonic channels (and PM operators / modulations, as required!).
Reworked File menu (from contextual menu), longer items, but now are more explicit.
VMEM 32-voice SysEx was designed by Yamaha company for the DX7 synthesizer. It’s a packed file format (a kind of ‘compression’, to save space), filesize must be 4104 bytes. It contains most datas for all 32 voices (a whole bank). However, OP ON/OFF switch states and MONOPHONIC states never appear in these SysEx files. This SysEx file format is the most common foundable on the internet.
VCED single-voice SysEx was designed by Yamaha company for the DX7 synthesizer. It’s a non-packed file format, filesize must be 163 bytes. It contains most datas for a simple voice (preset, if you prefer). However, OP ON/OFF switch states (for all 6 operators) and MONOPHONIC state never appear in these SysEx files. This SysEx file format is very rare, very difficult to find on the internet.
The “.6opdx” file format is designed exclusively for the 6OP-DX module (it’s a “proprietary” file format). It holds all 32 voices bank, but it includes additional datas who never exist in official SysEx, such OP ON/OFF switch states (32 x 6), MONOPHONIC states (x32), and the lastest selected voice number (preset). Filesize is always 4129 bytes.
Some 4096-byte SysEx files can be found on the internet. In fact they’re VMEM 32-voice banks, but truncated as raw format. Removed “F0” and “F7”, removed header chunk, removed checksum. This file format isn’t accepted by 6OP-DX module, because it’s not official, and basically not secure (without checksums, these files possibly contain corrupted datas).
Import DX7 SysEx feature detects automatically the type of the SysEx file (either 32-voice “VMEM”, or single-voice “VCED”), by checking its filesize and the header chunk. Also, it existing many SysEx files (32-voice) who have inconsistent datas inside them, despite their checksums are passed, for one or two voices. As example, official rom3a.syx file, voice #20 TIMPANI have an excessive value for OP2 EG L3 (in this case, the module’s logic fixes the bad parameters automatically, to stay in allowed range, during importation).
Thank you for adding the tooltips. Working well here.
Had an idea / another request. It would be useful if there was a visual way to distinguish, which individual operator modules are outputting sound based on the algorithm. While this is possible via the algorithm display, it would be cool if there was some type of indicator like an LED or some type of color difference on the module itself. So, it 1-3-5 are the outputs, those modules would have some type of indicator.
Yes, exactly re: LEDs, that’s how I’m imagining it. Just some sort of indicators re: operator outputs.
No problem, re: focusing on improving encryption for OhmerPrems for the time being. It’s unfortunate that you’re dealing with it. That’s very annoying to have to deal with that as a developer. Hope you figure out the right solution.
Blog - Thurday 26th Feb. - 01:00PM (13:00) GMT+1/France:
All modules (FroeZe and expanders, QuadPercs, and 6OP-DX) now are using the V2 licence file. All of them was sent by email to all OhmerPrems members last morning (France time) - please check your mailbox (and possibly junk/spam box, as required). In case of problem, please contact me in private, here, or by email.
As requested by member, here, I have added true RGB LED alongside all six OP OUTPUT jacks. Their colorscheme follow the colorscheme used to display current algorithm on the touchscreen: green for carrier operator (red for switched off carrier operator), white for modulator operator (LED turned off for switched off modulator operator). Fully operational.
The new LEDs along OP outputs (bottom right side of the module)…
Minor issue here
When I select “control knob with mousewheel” in VCV, each “click” of my mouse wheel increments/decrements 1 or 2 units on your 6OP-DX controllers (e.g. VOICE, ALGO). I can hold the CTRL key offcause to make fine adjustments.
It’s not an issue but normal behavior, because they’re continuous encoders, not knobs, who are controlling -VOICE+ and -ALGO+ (above leftside of the touchscreen).
They’re calibrated for “high speed” increments/decrements as normal usage by mouse drag only (I mean, by moving mouse while holding the left mouse button). Calibrations are strictly identical regardling all other modules such QuadPercs, FroeZe and KlokSpid MkII, to stay “consistent” between these different modules (aka to avoid change user’s habits).
The problem is due to the nature of a continuous encoder, it sends ±1, working as “relative”. Knobs (pots) are working as “absolute” values (from their min to max). It also the reason why you’ll cannot assign a continuous encoder to a dedicated mapping module, like VCV’s MAP or stoermelder’s MIDI-CAT.
Use mouse drags instead mouse wheel over infinite encoders! I precise mouse wheel is working fine over all potentiometers/knobs (from OP1 section to rightside of the module). So please understand it’s a “kind of compromise”, and be sure it’s impossible to please all of the people (all of the time). I’m sincerely sorry, because we’re falling in technical limitation.
If necessary, we’ll can continue this conversation, but in private. Thanks in advance.
I don’t understand why the stock LEDs colors are bad (in particular the blue component isn’t blue, but cyan). Strange colorscheme tables, IMHO. And why a true RGB component isn’t provided by default, because RGB LED are very common in our world, the most common usage on our RGB PCs are decorative LED stripes, or on fans…
Rack’s lights are a little less straightforward than one would hope, but you can get what you want without too much trouble:
For an arbitrary-colored light:
// ModuleWidget:
ModuleLightWidget* whatever_light {nullptr};
// ModuleWidget constructor.
// Can be any size and single-colored (not rgb) light
addChild(whatever_light = createLightCentered<MediumLight<WhiteLight>>(Vec(x,y), module, MyModule::L_WHATEVER));
// change the light's color.
// in the constructor, and perhaps ModuleWidget::step() for a color-changing light.
whatever_light->baseColors[0] = nvgRGB(r,b,g);
Brightness is set normally as for any light.
Because this is a “multilight” with just one color, it’s just the one color and not a lerped almalgam like the “rgb” light is.
But I’m more familiar about using “template” LOL Custom RGB is used 14 times, so a custom widget is useful. However, about the purple LED, used once…
My favorite development language was… Fortran and Pascal, the “old scool” since 1980. Turbo Pascal (MS-DOS enviroment), then Delphi in particular during decades… So coming in C++ (by VCV Rack) was a pain for me, today again I hesitate to use pointers (I’m afraid about crashes). About classes, it’s okay, however. C++ is more poweful, but more difficult to master, and sometimes Chinese is more easy to read. Even since 2018 (in my case).
Development daily blog - Monday, March 2st - 03:30PM (15:30) GMT+1/France time:
The news:
Reworking all free (open-source) Ohmer Modules! original KlokSpid module is now defunct, R.I.P. (it was as deprecated status during two years, so it’s time now to move forward). Successor is KlokSpid MkII, more powerful, entirely free for everyone in our Universe, from OhmerPrems plugin (license keyfile isn’t required for KlokSpid MkII, KX expander, and KordZ modules).
Stable OhmerPrems plugin was updated to version 2.6.7 (but with disabled 6OP-DX module, because it remains in development and… “silent” at the moment), in order to update previous v2.6.6 from VCV Library. Since 2.6.6 (Nov. 2025), they’re many enhancements and fixes, applied on all other modules, such FroeZe (and expanders), QuadPercs, KlokSpid MkII, and KordZ.
Development daily blog - Tuesday, March 3rd - 02:15PM (14:15) GMT+1/France time:
The news today:
Have entirely reworked “Model” management (GUI themes), more efficient, and potential crash fixed about KX module (left-side expander for KlokSpid MkII module) due to a missing return; inside a if (!module) statement (related to module browser).
Have disabled right-mouse click tooltips over continuous encoder and buttons for KlokSpid MkII module.
Another “Alpha” pre-release is planned during next night (approx 01:00AM France time).
Wednesday March 4th - 09:10AM (09:10) GMT+1/France time:
All “Nightly Build” packages are available. Internal stuff on all modules (“Model” aka GUI theme handler). Fixed a potential crash on KX module instanciation from module browser. No more right-mouse click tooltip over continuous encoder and momentary buttons concerning KlokSpid MkII module.
(please always see lastest post in this topic, below, for package download links - Thanks!)
It will be largely enough, attempting 3 x 16-frame. At the moment, 3x8-frame, “F3 performance” indicates around 0.3~0.8 (I’m using PC Windows 10, 2019 technology Intel Core i9-9900KF 8-core/16-thread CPU @ 4.5GHz overclocked, watercooled). GPU is NVidia RTX 2080 (8GB), displaying 1080p @ 60Hz (the limits of the screen).
(please always see lastest post in this topic, below, for package download links - Thanks!)
Number of polyphonic channels is always the minimum regardling these connected input jacks: mandatory V/OCT and GATE, optional VEL. (velocity), optional AFT. (aftertouch), and optional RETRIG. (retriggers) input jacks. Please notice both optional PW (pitchbend wheel) & MW (modulation wheel) are “monophonic”, by the way, actions on them during play will affect every polyphonic channels (and PM operators / modulations, as required!).
