Wishlist: Any chance of trowaSoft multiSeq port?

Plugins
21

ok, the key to the problem seems to be this module creates new light widgets.

in particular they derive from rack::app::ModuleLightWidget (which comes from LightWidget)

they then override

	void drawLight(const DrawArgs &args) override
	void drawBackground(const DrawArgs& args) override

however, these methods never get called.
in fact I can also override draw(const DrawArgs &args) and that never gets called either.

these are correctly added via addChild(), and are kind of present, as I can change the colour, as I can see that circle to change colour.

my guess?
something is losing the type of these objects, and is treating them as basic LightWidget, which is what the circle is likely to be, and hence why if I setColour() on it, it will change.

but no other overridden drawing is being done, due to lost type.

note: since they use the override in declaration, the compiler is happy with the inheritance hierarchy.

this overriding of ModuleLightWidget is being done for a number of its custom widgets, hence why we see these ‘circles’ instead of intended graphics.
Id guess, if the overridden methods start to get called, most of the issues will be fixed.

to double check, Id need to create a new test plugin to ensure there is not something else odd going on within the plugin.

however, given this plugin does work on the desktop with this code, it looks like its likely something in the firmware

thoughts @danngreen ?

what has made this pretty tricky to track down, and created a few false ‘leads’ is there is so much redundant code within the module, stuff thats not being used, but looks like it might :frowning:

22

Ah… ok, so the MM does not call the draw*() functions for every widget (doing so makes the GUI unusably slow). It strategically calls draw() and drawLayer() only for widgets that it doesn’t know how to render natively. Which means anything that it recognizes as a LightWidget, ParamWidget, or PortWidget will be rendered natively, and only widgets that are unknown will be drawn. Basically, anything that’s added via addChild and doesn’t get caught by one of the overloads in app/ModuleWidget.hpp in the SDK, will be added as a “graphical display”. In addition, if the ModuleWidget itself has an overload for draw() or drawLayer(), it’ll be a “graphical display”. All “graphical displays” get their draw() and drawLayer() functions called when visible on the screen, and all other widgets are rendered natively without ever calling draw*().

ModuleLightWidget is sort of a border-case. If the widget has a non-zero number of colors (widget->getNumColor() != 0) then the MM will use it as a light. But if has 0 colors then the MM can’t really render it as a light so it renders it as a “graphic display” and therefore will call that module’s draw() function. I’m not sure the reasoning for the practice of creating lights with 0 color, but some plugins are doing that so I added that bit to support them.

The default overload for LightWidget::drawLayer(args, 1) will call drawLight(args), so that should work. But I don’t think drawBackground is called from anywhere.

Also, keep in mind drawLayer() is only called for layer==1, never for any other layers.

Edit: some docs on this (less detailed than what I just wrote): metamodule-plugin-sdk/docs/graphic-displays.md at main · 4ms/metamodule-plugin-sdk · GitHub

And yeah, the way the MM natively renders a light is with a circle. So that explains the circles.

23

hmm, thats quite a deviation from vcv behaviour…
I did notice your implementation of LightWidget was ‘lighter’ than the vcv implementation, but assumed it was taking a different approach.

I’ll have to review this info, and think if anything can be done.
this plugin is doing this a lot as a means to create ‘custom components’.
my fear is, even if I can hack around it, without butchering the code base - its sounds like, the MM might have an issue with rendering performance.

but I’ll have to get some time to play, to understand a bit better what MM is doing, then see if I can find an approach that might work for these plugins.

24

Still hoping this is possible.
Bumping thread not to apply pressure, just to keep hope alive :crossed_fingers:

A version of this that essentially is a “player” (of sequences created in VCV) would be totally acceptable/welcome for my purposes, as long as it had full functionality otherwise (mainly working song mode). Editing deeper projects on the MM would probably be quite painful anyway, but I would find it extremely useful as a preprogammed song sequencer.

25

same with seq++ module by squinky! nbd if it can’t be fully editable on mm, we can just set these more complex ones up (that require a lot of mouse interaction) in vcv and utilize the basic functions on mm like switching sequences, that would certainly still be more than great enough imo

1 Like
26

unfortunately, by the time I worked out what the issues were - Id put in a reasonable amount of effort, and felt I had zero results - so was a bit demotivated, so kind of dropped it.

really the only way forward was either :

a) re-write the entire UI
difficult/time consuming, because the UI has quite few modes / functions to replicated.

b) create some kind of compatibility / framework
so re-use the high level functionality, but come up with a lower level replacement thats compatible with the MM. again a lot of work, and I was a bit concerned about the performance. there are good reasons why Dann optimised the controls in the way they are.

I guess, most likely, it be a hybrid of the two

the issue for me was, this is no longer really ‘porting’ this is a re-write,

also as I pointed out from the outset, I always had a feeling the UI was just a bit too complex to be useful on the MM. it’d be uncomfortable to use.
thats ok if its a quick port, but beyond that ?!

as for a player, hmm, yeah, this is ‘easy enough’, and I get for an end-user why its attractive, but as a dev, it feels like it’d be half-baked - not very satisfying, and you still have to ‘support it’.

so, its a tough one, for me personally, I think some modules are not that attractive to port - the effort / “reward” ratio for the (3rd party) dev just isn’t really there.

by reward here, I simply mean the fun / satisfaction of development…

at some point, if Im spending that much effort on dev, Id prefer to spend it on my own projects. e.g. I wrote a cartesian sequencer (CART) for the Percussa SSP that was inspired by Make Noise Rene. Id be much more inclined to move that to the MM.

perhaps its also a control/ownership thing…
if I ported/re-wrote CART for the MM, I could do what I like… do it in such a way as it retains compatibility with the SSP - so if I add features for the MM, they can be ‘back-ported’ to the SSP.

so yeah, honestly… perhaps one rainy day, I might open up the project and take another look . however, realistically, when Im back in dev mode (over winter ;)) - I really want to get my other (including MM) projects finished, and they’ll take a priority.

3 Likes
27

Hey thanks for even taking a stab at it. I’m totally grateful for the time you’ve already spent. My main motivation for wanting this particular sequencer in MM format is to have a repeatable “song” format in my rack, and I just happen to have tons of past experience using the multiSeq. Plus I’m old and set in my ways :rofl: sometimes and I get stuck on “loop” with some of my ideas. If it’s not gonna happen- and based on your reasoning (sound and understandable) I’d say chances are slim that this project is anyone’s future, which is ok.

I was looking for a way to keep all this “in the [modular] box”, but I do have an ipad and the CME WIDI Bud, so I can probably figure out something with that…Cubasis seems like a good choice. Pity there aren’t more sequencers in VCV with song mode, let alone on the meta. I realize most modular folks aren’t really trying to “repeat themselves” so it makes sense. I’ve been at this a long time though. Patch from scratch and generative stuff is great and I can do all that and it works great for fun and for streaming formats, it just doesn;t help when you want to play in a “band” format with other people, lol.

In any case, @TheTechnobear I really appreciate you taking the time to try, and the explanation as to why it’s a less than ideal process.
Thanks! :control_knobs:

2 Likes
28

in theory one could set up the trowa multseq (or even a midi player like seq++) the way they wanted in vcv and multi record the outputs, the cv, into individual .wavs (maybe using nythsi’s polyrec64). the .wavs could then be loaded into a series of 4ms basic wave players (that are all setup to trigger/play at the same time). a bit of leg work up front but this method could generate more set song oriented cv structures directly on the mm

also a .wav file of trigger/gate pulses could still be run through a bernoulli gate for added generative

only drawback, beyond the initial setup and legwork, is that it can take a little while to preload longer .wavs in the wave player modules. so if there was a need to switch quickly between songs/patches, that could be an issue. also wavs aren’t clockable or speed controllable, at least with the basic wav player. so yeah for more control, an external solution like ipad or laptop would probably be best

29

Hi @slaughtrhaus ,

Have you looked into using one of the many external MIDI sequencers in your live setup, then use VCVRack or MM as a multi-timbral box of magic receiving MIDI, and outputing audio ?

I have the Oxi One (Mk I), and the Arranger mode works very nicely driving either a VCVRack patch on my computer, or connected directly to the USB port of the MM. And the user experience of using it is just going to be way way better than any VCVRack / MM module.

1 Like
30

Hey @phommed-

Using the MM as my main sequencer (in the specific case of using song mode to produce complex, repeatable sequences) is the main goal I am discussing here, as I am very satisfied with the oscillators and filters I have collected over the years in hardware modules like the Furthrrr Generator, Polygogo, Rings and Braids.

And yes I’ve owned many different midi sequencers in the past- Octatrack, Pyramid, and various others. This workflow and working outside the confines of my case are what I am trying to avoid quite frankly, along with yet another substantial outlay of cash I don’t really have. I can appreciate your point of view and you are correct that I could do it that way, but I (respectfully) do not agree that it would be “way better” for what I am trying to do. I’m not saying it’s a bad suggestion, just that I am trying to do something else. :peace_symbol:

1 Like