Explaining "porting" to a programmer

Greetings-
I am working on getting a particular module (trowaSoft multiSeq) ported to the meta module. Since I definitely don’t know enough programming (I know some SwiftUI but none of this stuff) to pull it off myself I have been looking on Fiverr to find someone who can. Since i don;t really understand the process well enough myself, I find myself slightly out of my depth trying to explain what I want to prospective hires.
What I mean by this is since I haven;t done it myself i don;t know simple things like will knobs, buttons, and jacks that already exist on a module simply be recognized by the plugin once ported or do I need to specifically ask for some kind of mapping to be done to each individual control for them to work once ported? I’m aware that controls that depend on the mouse need to be adapted somehow to be controlled by the encoder or the pots so that’s easy enough to explain that it needs to be done…

I guess what I am asking is how much do I have to explain (taking into account that I might have to explain some musical concepts along the way) vs. what things will just “happen” during the process of porting? I know I am asking a lot and the responses won’t be short or simple, so anyone who dares answer, you have my gratitude in advance, thank you.

I took a quick look at this.

as this modules (trowaSoft multiSeq) is open source the process to ‘port’ it would be relatively straightforward for a developer that knows something about vcv development.

however, I note, that this module includes OSC support.
this functionality could not be ‘ported’
(unless you wrote custom firmware for both the MM and the wifi expander, which is beyond scope)

this mean the developer would need to strip out this code, which could get messy.

as for the UI change…
this is a functional change, the ‘issue’ will be the UI will need redesigning.
obvious approach is using 2 knobs for row/col selection and button for value change.
also the panel will need redesigning/making larger, to allow for these knobs.
though, you really need to think how ‘usable’ this will the module, Id say it’ll be pretty painful/unpleasant. ( * )

also bare in mind, that you are (I assume) expecting this 3rd party to also test the ‘port’,
whilst they could test the changes (removing osc, add ui) in vcv on a pc, they’d not be able to test the code on the metamodule unless they have one.

ok, you could say, you’ll test it for them - this might work, if you dont run into complications, but if you do - they aren’t going to be able to debug the issue properly… and that’ll cost time, and so a ‘hire’ would want payment for this.

so… generally…

Id not give this to anyone unless they have specific VCV rack programming experience, and so also some knowledge of things like sequencers etc.
(generally ‘domain’ knowledge is pretty important for programmers)
in that case, you’ll not need to guide them at all, except how you want the UI to ‘work’ as a user.

at that point, if things go ‘ok’, then there shouldn’t be an issue - but if there are complications, you might have a problem. as Im sure no one is going to have a 4ms MM ;).

overall, Im not sure, Id recommend it
as whilst its a relatively easy task, I’d not be surprised if you pay out and never get what you want… but I may be wrong, as Ive never used fiverr before.


( * ) personally, I think these kind of UI changes/limitations are the reason so many vcv modules are ‘unsuitable’ for the MM. its not that technically, you cannot port them, but rather you end up with something that is not very desirable.
its ok, if the plan is that you make the patch on vcv and never touch it on MM, but thats often not the case.

1 Like

First of all I want to thank you for comprehensive reply, I really appreciate it. Every thing you’ve said makes total sense.

I’ve actually started working with someone on this port and your knowledge on this subject is invaluable to the idea/project, so I will be passing it along to the programmer. Luckily, some of the main concerns were things I did happen to understand from the beginning and was able to explain to them, like getting rid of the OSC control code, the necessity of me testing the plugin and the possibility of multiple revisions to succeed.

Regarding the UI changes I had not considered the idea of adding actual knobs to the UI itself but instead was thinking somewhere along the lines of using the encoder to scroll through steps, pressing it to access the parameter and turning the encoder more to change the parameter, and finally pressing it again to resume scrolling through the steps. Unless this isn’t feasible for some reason I do not understand (possible, probable even lol) this is the plan right now. And yes my main plan is to program sequences in VCV patches and then move the saved patch over to MM.

And yes I fully realize that I might be “chasing an untamed ornithoid without cause” (lol) here and that I might be spending my money on something that won’t work ever. I can only hope that the programmer’s confidence in their ability is accurate and warranted I suppose. The investment was small enough to not worry on that level too much considering what I will get if successful would cost magnitudes more to have in hardware module format. After spending a few days reading here, this is a project I would never ask/expect someone from the community to take on for free though and I really want it so this seems like the way forward for now. If it works out I plan on making it freely available for the community as well.

This community is a wealth of knowledge and I am grateful for its existence.
Thanks again for the reply!

1 Like

cool, as long as you know what you are getting yourself into then there is no issue :slight_smile:

as for UI, this was just a ‘random’ idea, there are ofc, many different ways to achieve something ‘usable’ on the MM… and it assumed you wanted at least some level of control on the MM.

taking a quick look at the code we see

	for (int s = 0; s < numSteps; s++)
	{
		// Configure step parameters:
		configParam<TS_ValueSequencerParamQuantity>(TSSequencerModuleBase::CHANNEL_PARAM + s, MULTISEQ_STEP_KNOB_MIN, MULTISEQ_STEP_KNOB_MAX, 
			/*default*/ defaultStateValue, /*label*/ "Step " + std::to_string(s+1));		
		oscLastSentVals[s] = MULTISEQ_STEP_KNOB_MIN - 1.0;
	}	

so this means that the module should have one parameter per step, which Id assume you will see in the parameter list when you bring it up on the MM.
however, that also means you are just going to end up with a list of 64 steps, which is far from user friendly.
also… it’d mean you have no chance to control step values by mapping to hardware pots.
(unless you have a lot of expanders :laughing: )

hence my suggestion for a kind of meta control which would allow you to move thru the steps in a more use friendly way - be that row/col, or even just simple step number.

but if you don’t need UI then it’ll ‘work’ for the odd tweak.

again, it all really comes down to user experience.
thats what I mean, quite easy to port a module and have it ‘functional’ e.g. by going thru a parameter list - but not very user friendly.

however, I’ll admit - this is my personal opinion, and how I like to develop and also use my MM. I like it to be hands-on, and given the limited form factor on the MM I prefer few controls.
(something like MI Plaits is a great example… a few well chosen parameters, makes it a great design for use on the MM)

but for sure, if you do the majority of your patching on the desktop, the UI on the MM becomes a pretty moot point - as you’ll just use macros for a few choice parameters :slight_smile:

1 Like

I don’t know if module author j4son is registered here but I did make them aware on discord that this is something people would like. I messed with using AI tools to help me port it, but I’m not a C-language programmer and it’s over my head :slight_smile:

if anyone ever makes a module that runs nodejs for some terrible reason, that will be my moment to shine, no doubt :-p

there was some small chat about porting “prototype” module over to mm plugin. it works be quite powerful! but im skeptical the port would ever happen.

Just to follow up on this for others possibly thinking about this route-

The Fiver programmer didn’t work out. I knew it was unlikely to pan out so I’m not angry or let down. Oh well- As they say…nothing ventured…