Was wondering how to best package it, and relying on system-level JACK is not a good idea, as it then needs to work in a certain way (pipewire changes quite a few things for one…).
So one crazy idea is to reuse the portaudio layer as used in Windows builds, but on Linux.
This is a bit awkward for those that understand the linux audio layers, but we have here a JACK server running on top of PulseAudio
Ideally this would still allow to connect to a running JACK server (or pipewire) but doing it in a self-contained way. Otherwise we get a bunch of edge cases that easily break the expected runtime behaviour (for example 2 mod-host instances running at the same time, a big no-no)
With that in place I am now trying to get automated builds going, so it is easier to try out any changes from our side and also requests from community. Will let you know once those are ready for testing.
Actually, one of my concerns is that this will cause problems with creating patches that can’t be ported over to the gig-friendly format of the Dwarf or even to the MOD DUO X. Sometimes limitations are an advantage to the creative process.
Would be great if there was a mode to cap the ability of the software to not exceed the limits of the hardware units. That way the hardware can remain relevant and hopefully continue development toward newer models (flagship MOD DUO Z, anyone?)
For those used to how GitHub actions work, the link to follow is Workflow runs · moddevices/mod-app · GitHub
This now includes a Linux x86_64 build too, I had to make it build on a Ubuntu 22.04 base so people in older distros won’t be able to use this. It requires Qt5 installed system-wide for the GUI, but I expect most users to already have it as it is very common.
A few plugins are still missing on these automated builds compared to the previous releases where I manually built a few extra ones (aida-x fails to load on win64, mda and fomp missing, spectre and notes missing on macOS).
Once those are sorted out we can tag a new release
I like the idea of that desktop app for it’s general coolness, but I am curious to know what are supposed use cases exactly, to line up the expectations.
For what I can think, there are three types of people who might use that.
People without MOD devices - these can
try Desktop as a fancy try.mod.audio alternative, to have a taste of the platform possibilities with a hands-on experience. Hope you would let us know when Desktop would be good enough that it would make sense to spread the word.
Buy some hypothetical future paid extended (vst powered, for example) and complete version of the Desktop, or donate, or whatever.
Developers - These might need
A way to test out plugins they are developing, fast, on the Desktop environment, reducing a feedback loop. In a best scenario - some automation that would allow to build and deploy plugins into the running Desktop pedalboard with automatic replacement of the plugin instances on the pedalboard.
Be able to help and customize python part of the software. This would require some understanding and guidelines on a correct way to modify python sources for the Desktop and how that can translate to changes of python code for the actual hardware devices. At least in a broad strokes - what is the intended workflow here?
Non-dev people a with hardware MOD devices.
Might use the same processing on desktop and hardware MOD. This might need:
Possibility to toss pedalboards between Desktop and hardware, so you could prepare pedalboard on PC and use it on hardware later.
DAW integration (VST or something)
Same set of plugins that we have on hardware MOD, including your paid plugins?
I see possibility of some kind of a “reamping”, pedalboard-wide, like you play and practice and record with a hardware pedalboard, but can reapply similar effect chain “in post” to the raw input record, based on the same pedalboard but using heavier neural models and some late tweaks in Desktop.
Are any of these fantasies in line with the MOD’s vision on Desktop App? At this point I feel like I am guessing a lot while it is important to perceive this app correctly, in the context of it’s intended future.
I’m not speaking for MOD of course, but a few things I’m intrigued about:
Having additional input channels (via audio interface) means I can input multiple instruments / mics, which will be great for band rehearsing and experimenting, and work well for how I like to loop and jam with multiple instruments. For a while I’ve envisioned a rack-style MOD device, or a “mixer with MOD inside”, and this is a good approximation.
With my shiny new Mac M2, I should be able to go deep into complex pedalboards, though that’s not my main interest. But I should have enough horsepower to be able support something like multiple signal paths with each having some combo of AIDA-X, IRs, convolution reverbs, harmonizers, recording, looping, RMPro… you get the idea.
I’ve long tried to get “band-in-a-box” capabilities, and while all the pieces are there in theory, for practical use the experience isn’t always great. For example, I’d prefer to use the streamlined interface in EZDrummer for building and arranging beats, rather than assembling sequencers, MIDI filters, etc. Being able to run other tools side-by-side will add a convenience factor
I’ve had a lot of ideas for improving the user interface and adding options for power users over the years. I’m optimistic that this will finally open the door to wider collaboration
As a MOD owner, I have wanted for a long time for a way to experiment with plugins and pedalboards without having to whip out my Duo, my guitar, connect the PC and stuff.
With a desktop app all I need is some prerecorded guitar riffs and licks and I can try how they sound with any distortion, amp or cabinet from my couch. I could even do this at work in my lunch break if I wanted to!
Ad a developer, well, I see the great advantage of being able to compile and test plugins without the step of loanding them on the device with each build.
This is an idea I had not considered. I’m still trying to get back into the mindset of a developer, something I was never very good at - couldn’t focus and concentrate (or didn’t want to) on the nuts and bolts part.
Taking already recorded wav files and running them through various plugins - particularly distortion - is an area I’d like to start focusing on.
I’ll try to stay abreast of the latest plugin developments and maybe start by looking at the with the ones with the most interest, but my own interests will probably be the greatest influence in determining where my efforts go.
As for the documentation - I’ve always been terrible at documenting what I do in solving a problem, so taking into account my own shortcomings with available documentation I’ll try to focus on that as well. I’ll need to throw stuff out there for people to rip to shreds and tell me I’m an idiot - advancing age has demonstrated to me the disadvantages of being too “ego-involved” in something.
Needless to say, just playing music is going to command most of my attention!
That’s my latest approach to tuning pedalboard currently. Record a piece in a lp3 looper, and tune pedalboard while loop is playing until it sounds reasonable. When you have a hundred of impulse response files to try, it would take eternity if you have to play the test piece each time (and it would be still not a clean experiment, if you play a bit differently each time)
Only problem is that listening the same piece again and again is a bit annoying. Probably better not to play something you really like, as you gonna hate that piece anyway, just like any morning wakeup alarm ringtone.
lol. yeah… i’m typically looping bits of my own playing, rather than tracks… cuz i want to test the response of the board to specific aspects of what i’m playing.
same risks as what you mention, of course, but it also means that i’m usually changing the bit of playing that i’m working with fairly frequently, once i’ve addressed specific issues in the board.
In my case I’d like to work with existing wav files that others have created. I have the equipment necessary to record the samples, but not enough room to set everything up. Recording the samples looks to me like the most time intensive part of the process, and the only reason anyone would do this would be to create a model in the first place.
I would imagine that not many who have gone to the trouble of creating the wav file(s) would skip the step of creating the model.
If I’m right about that then there may not be a need for this approach.
I’m undoubtedly using the wrong terminology in much of what I write.
Currently I’m finding the myriad of tonal capabilities of Gian’s Fender models to be really fun to work with. I may not even get to the Marshalls.
Not sure who you’re replying to, but I essentially agree with you. I still believe that it’s useful (at least for me) to start with a rough idea of what I want to achieve and taking the individual contributions of others and adjusting them from there.
That’s what the mod team (and I include the entire community in this) has accomplished thus far and this is just the starting point. For my own purposes the duo, dwarf and footswitch extension have been extremely useful and flexibile - but just the starting point.
Having been away from the project for a bit while dealing with other issues I’ve come back to find another dimension (we “are traveling through another dimension, a dimension not only of sight and sound but of mind.”) to the project, more flexibility and more opportunities for achieving our individual goals in search of our ideal sound(s).
I’ve got a pretty steep learning curve here, but it’s going to be a fruitful one.
I don’t know if any of what I’m saying in this and my other posts make any sense or are relevant to our purpose, but I find this thread to be very inspirational.
There’s plenty of raw material here to fine tune individual components to our liking. I don’t know about anyone else but I’ve got ideas of what I want to achieve and hope I’m never fully satisfied with my efforts.
right yes, main issue is that plugins were never tested with 64, so the 128 is the default value.
I think if we have a little warning saying 64 samples is experimental, then all should be good. users will know to try 128 if any issue happens.
those plugins will all appear as “tuna can” pedals, which doesnt look very nice.
but thinking more about this, perhaps we can make this optional. so it is off by default, perhaps another little warning for this too (mostly to explain what it entails)
by the way, just noticed some serious regressions on the 0.0.2 release, issues regarding needing to connect things twice are related.
finally have a setup that is handy enough for quick development, so I was able to sort out a few crucial details. that also means a little more attention to the Linux build, since that is the main one used for development (MIDI confirmed working now, with a setup similar to a2jmidid)
Fixed all major issues that I could find on Windows, except pedalboard screenshots which is a bit more complex to handle and not mandatory for having everything work well so I am leaving that aside for now.
Also a little rework of the GUI, for more clearly outlining what is going on with duplex vs separate IO vs output only mode.
And because I hate looking at super bright windows all the time, a bit of integration with Windows dark mode too.
It is starting to behave like a real, professional tool.
Some of the panel/settings GUI options can be unclear if you dont know what they are meant to do, would tooltips be enough for those?
