A port of multiSeq would be amazing. I’ve been looking for friends who might be able to do it and even sending a few messages on Fiverr. It’s been a part of my VCV workflow for as long as it has existed…if anyone here has any interest please get back to me.
PS this project is amazing thank you to everyone involved!
I doubt if this actually works, but I don’t yet have a metamodule to test with. Had to remove OSC, aggressive refactor with no way to test, but it compiles 
4 Likes
Wow!
I will happily test later after work and provide feedback. Working or not, I appreciate you taking the time to try. Thanks!
Let me know what happens. I should have a MetaModule here within a week or so, as well. I also pinged the author of the original artifact on Discord to let them know what I am up to. We’ll see.
You should be able to build this yourself (Flox is doing all the env sanity setup stuff) but for convenience I slapped a built .mmpatch into /build/
I shot them an email as well, and have not heard back. Thanks for the built version, my coding skills are painfully limited… 
Meta module got delayed it shows up later today, will test ASAP.
Hey I tried the plugin, no dice…
Some controls and jacks pop up on the screen but they aren’t mappable. I really appreciate you trying, if you want to keep trying I will certainly keep testing.
Thanks again 
Yes, I can probably replicate that now, but this is a bit over my head. I pinged the author to see if they have any bandwidth to help me.
What are the most important features here, besides OSC stuff that looks probably impossible?
Most important features would be all the basic functionality of the module excluding OSC which definitely isn’t necessary…
- 64 patterns.
- 16 channels (outputs).
- Output modes: Each channel may have its own separate output mode.
- TRIG (trigger) (0 or 10V)
- RTRG (retrigger) (0 or 10V)
- GATE (continuous) (0 or 10V)
- VOLT - Voltage (-10V to +10V): Output whatever voltage you want.
- NOTE - Midi Note (-5V to +5V).
- PATT - Pattern (-10V to +10V): To control the currently playing Pattern (or Length) on another trigSeq, voltSeq, or multiSeq.
- “Song Mode” Internal Pattern Sequencer: Setup automatic pattern changes so you don’t need another sequencer to send CV into the PATT input. Up to 64 sequences.
- Inputs: Pattern, BPM, (step) Length, Clock, Reset.
- Copy & Paste of channel or entire pattern.
The feature that makes this module a must have is easily song mode. That combined with all the different forms of sequencing it does simultaneously and the 64-pattern capacity put it in a different league than most other offerings on the platform. These abilities fulfill personal goals of repeating myself for “band” purposes quite elegantly, and without the need for external hardware sequencers…
And FWIW I emailed the author before making these threads and haven’t heard anything…
as, Id commented it’d be relatively easy here, thought I should put my money where my mouth was 
so had a quick crack at it…
not sure, how functional they are , partly as Ive not even loaded them up in vcv so dont know how the modules work.
voltSeq
I know you didn’t ask for this, but it actually comes for ‘free’, as the MultiSeq is a specialised form of it… which also means, its probably worth test / getting working first, as its the foundation.
overall seems ok on initial glance, UI is up, its moving thru steps, parameters available
but I really need to load it up in vcv check out how it works, then test (and no doubt fix it)
MultiSeq
this one is not doing anything, e.g. I cannot see steps animating, but not sure if its suppose to in an unconnected state - again, need to really test in vcv - then can go from there.
overall, UI is up, parameters showing, doesn’t crash (lol). im not sure how functional it is.. as I can see much going on - but again, I need to play with it on vcv to see what its supposed to do.
however I suspect this’ll require a bit more extra work over the voltseq.
general approach
took me a bit longer than expected, as I decided NOT to just rip (osc) code out of the vcv module code base, but rather to make it conditionally compile with or without OCS support.
this has a few (big) advantages :
a) code could be merged back into the original authors code base
b) future updates from original author can easily be merged in
c) for debug/testing, I have the original code still in place - so easier to see which changes may have caused issues
the main disadvantage is its a dev slower process, at least initially, as it requires a lot of ‘conditional’ blocks - and frankly, the osc code is very tightly integrated into these modules.
(went a bit deeper than I was expecting tbh)
I’ll also say there are some other ‘oddities’ with the original code, their is a bit of a misalignment between the Rack API version it uses vs the one used for metamodule.
I think possibly, the module uses an older version (of v2) that the one used by meta module.
that said, its only in a few places, but could throw up some extra bugs.
so… next steps.
a) get familiar with the original modules
so, I have an idea what they are suppose to do 
b) test/fix my VCV desktop build with and without OSC.
this’ll allow me to know the changes have not broken the desktop
c) test/fix the metamodule build
once I know the desktop build works, then I can see if the metamodule ‘port’ has introduced any oddities.
all that said, no promises/timescales, I’ll fiddle with it as I have time.
but thought id show, where my quick dabbling with it.
frankly, its very hot here (Spain) and getting hotter…
so not sure how much dev time I’ll have…so spend the days at the lake with my dogs
4 Likes
It’s exciting just seeing it on the screen. Thanks for taking a crack at it! I’ve seen news stories about how hot it is in Spain over the last few summers. I was there as a kid in the 80’s on vacation and I remember thinking it was pretty hot too, and I lived in Florida back then lol. I look forward to hearing more when you can get to it, but in the meantime, stay cool haha. Thanks!
ok, got another hour or so…
some good news
Ive now built for vcv desktop, and seems to be working fine with my changes.
as a side effect of getting that to work, trigSeq and trigSeq64 are also now running on the metamodule.
I then did a bit more testing on the meta module for all 4 modules.
I found I could
- create a patch on the desktop , set up patch with sequences
- transfer via wifi too MM
- see that the sequencers were running and also pushing out data (as created on desktop)
this worked for both my desktop version, and the vcv library version of modules.
(the latter, ofc, is what end users will be using, my versions are just for ‘dev/testing’)
however, they are complex modules, so there may be issues that Ive not found yet.
(also I spotted some oddities even in the vcv rack library versions)
note: Im using latest source code (v2) of trowaSoft GitHub, so its possible got some ‘dev’ code in its that not been released yet. Ive not checked if, latest commits are post last release on vcv library… that said, behaviour seems same between my build and vcv library.
so, it currently looks like the oddities on the meta module are mainly about UI/drawing.
(we know its the metamodule, as my changes are fine on vcv desktop)
the issues I see are :
(and you can see in above screenshots)
a) custom fonts
I need to check but im not sure these are being used in all cases.
I checked mm sdk doc, they should work, they are in the assets directory.
so , I need to see if theres some kind of ‘limitation’ being hit.
b) custom drawing
theres quite a bit of this going on… and some of its not working esp, the individual cells.
im assuming some kind of differences in behaviour of the nvg* calls between desktop and metamodule implementation.
the ‘custom drawing’ ability was added in the MM 2.0 firmware, so could be this plugin is doing things that others have not.
c) sizing of module
this is a strange one, so the svg/png used by trowasoft are all of a fixed (and very large) width, rather than being the width of the module, as see by the module.
the code then resizes it with the following
{
SvgPanel *panel = new SvgPanel();
panel->box.size = box.size;
panel->setBackground(APP->window->loadSvg(asset::plugin(pluginInstance, "res/multiSeq.svg")));
addChild(panel);
}
this doesn’t work, seems like the MM is taking the width of the svg/png and using this instead.
at least I think thats what’s going on, as with all the above its working within vcv ok.
any ideas @danngreen ?
(just off the top of your head… Ive yet to dig into deeper yet)
anyways, quite a few drawing oddities, but at least its functional.
Im wondering about trying in the metamodule ‘simulator’ to see if the oddities exist there too. but I need to mess about setting the build up for that, but probably worth it given the number of oddities im seeing - also would be useful for other MM projects Im working on.
note: all tested on 2.0.11 firmware.
1 Like
Yeah, the call to addChild(panel) will invoke the overload for addChild for SvgPanel* which will store the path to the PNG. It’ll spit out an error to the console if the ModuleWidget box.size differs than the png size (see vcv_plugin/export/src/app/ModuleWidget.cpp around line 91 in setPanel), but it uses the PNG size since it has to know that in order to properly load the PNG file.
RE: fonts, there is some automatic re-sizing and adjusting done in src/gui/fonts/ttf.c, since in general just scaling a font down doesn’t always look right. Currently the firmware will make a manual adjustment to ShareTechMono-Regular to boost the size. In general though, if it’s reading the right font file but still looks wrong, I’d suggest conditionally adjusting the font size/position/color if needed for the MM build. There are some warnings printed to the console about fonts which could be useful.
IIRC the main thing not supported is textures. It’s all happening in vcv_plugin/internal/nanovg_pixbuf.cc if you want to dig into it.
Text rendering is different because our LVGL engine is substantially different from NVG in how it works with text. But that mostly effects alignment and multi-line text (might need manually tweaking)
ok, so I have the simulator running with the plugins - same issues, so thats good
btw: the simulator cannot load yml for these modules as they are too large
(800kB about 200kB per module :))
doesn’t seem to be a problem on hardware… I’ll need to dig into simulator to see where the limit is hitting.
anyways… should the simulator spit out these warnings (to console) ?
(re panel size)
I guess what I can do is just resize the PNG files ‘manually’, just got to determine what the correct width is!
simulator does seem to load some fonts, so could just be related to the custom drawing stuff.
as that all seems a bit out of whack, perhaps text is bring written out of bounds of something.
though simulator is not logging anything obviously ‘bad’
Loading ttf LTStopwatch-Regular from disk path trowaSoft/Fonts/LTStopwatch-Regular.ttf, 52844 bytes
FONS: Adding font LTStopwatch-Regular with handle 1
Loaded font trowaSoft/Fonts/LTStopwatch-Regular.ttf, with handle 1
Loading ttf Electrolize-Regular from disk path trowaSoft/Fonts/Electrolize-Regular.ttf, 52404 bytes
FONS: Adding font Electrolize-Regular with handle 2
Loaded font trowaSoft/Fonts/Electrolize-Regular.ttf, with handle 2
Creating label at 12,20 a:0x2 sz:12 (lv: 6)
Creating label at 12,13 a:0x2 sz:18 (lv: 9)
Creating label at 21,8 a:0x1 sz:6.5 (lv: 3)
Creating label at 21,11 a:0x1 sz:6.5 (lv: 3)
Creating label at 21,14 a:0x1 sz:6.5 (lv: 3)
Creating label at 41,20 a:0x2 sz:12 (lv: 6)
Creating label at 41,13 a:0x2 sz:18 (lv: 9)
Creating label at 70,20 a:0x2 sz:12 (lv: 6)
Creating label at 70,13 a:0x2 sz:18 (lv: 9)
Creating label at 102,20 a:0x2 sz:12 (lv: 6)
Creating label at 102,13 a:0x2 sz:12 (lv: 6)
Creating label at 130,20 a:0x2 sz:12 (lv: 6)
Creating label at 130,13 a:0x2 sz:18 (lv: 9)
Creating label at 159,20 a:0x2 sz:12 (lv: 6)
Creating label at 159,13 a:0x2 sz:18 (lv: 9)
Creating label at 141,4 a:0x1 sz:7 (lv: 3)
Creating label at 30,4 a:0x1 sz:7 (lv: 3)
anyway, will debug it later…
just wanted to know if there was anything obvious to check for, to save me time
edit: yeah, those labels are all fine… it’s other text, which much be being done ‘differently’ that are not being displayed - some digging needed
@danngreen do you remember any bit of code
which draws a circle , when it cannot do something else ?
Odd question I know , but I’ve notice a couple of bits where text graphics are missing there is a circle drawn instead - which does not appear to be in the plugin code.
Hm… there’s rectangle for missing characters in text, but I can’t think of where a circle would be drawn. Filled circle or outline?
filled I think… you can see here
see how run/reset/paste all seem to be replaced with a circle.
and also the text thats used for the voltage number…
obviously 2 different use-cases with the plugin code, but seem to have been substituted.
also interestingly, looks like the custom drawn jack seem to be the same circle.
(didnt notice this before)
note: these plugins all use custom drawn controls, the panel (background) is just blank, with just the title (voltseq) at top and towaSoft at the bottom.
(so we know these circles are being drawn, not just ‘showing thru’ from the background panel.)
anyways, don’t worry, I’ll figure it out soon enough - just wondered if it would trigger a ‘memory’.
EDIT: ok, I think I know whats roughly going wrong.
these are all derived from SvgSwitch, but for some reason the ‘svg’ frames are not loading, and possibly also not the fonts.
so we basically just end up with the default svgswitch.
not quite sure why yet, as the assets have been converted/are present. and the module is using asset::plugin
but I can check this in the simulator.
EDIT 2: red herring… kind of..
the SvgSwitch is being drawn, but it turns out another ‘TextLight’ (see next post) is being drawn over the top of it… and thats the source of the issue - not the way id do it, but hey ho…
Excitement intensifies 