I think that this is an obvious direction forward in capabilities that is being avoided by TE due to design elitism around minimalism and structured limitation.
It’s becoming clear to me, and probably to most owners that use the device for anything more than very traditional, structured and aged ideas of certain genres (or for longer than a month), that core limitations that hold this device back in terms of sound design capability, sequencing workflows and creativity, are not likely to be lifted within the lifetime of this device, if not for a highly implausible OS update containing vast amounts of content, or a slow, years-long drip-feed of updates that will only ever add a fraction of what the community wishes would be possible in this device format and size bracket. Admitting that this device is a really cool idea with enormous potential that requires software development work that might be beyond the reach of a team as small as TE is therefore, in my eyes, very noble and admirable. There’s nothing wrong with that.
What is wrong is to let ego limit progress. There’s a lot of ego involved with this device - some buyers’ ego and designers’ ego trying to present the design concept as complete and without flaws, or trying to present the mountain of potential, planned or suggested features as something one small team can wrangle on its own. It’s okay to have a healthy portion of doubt. So I’m putting forth that opening the device to custom user content beyond samples and presets, i.e. custom audio devices, custom effects, custom sequencing devices, would be amazing. By extension of that, opening the device’s OS, while less plausible, needs an updated 2025 discussion. I want to hear your voices on this idea. Maybe TE will be gracious enough to hear us as well.
I wholeheartedly agree! It’s a perfect test, I’d say, and it makes me grit my teeth, since I was really expecting something powerful, both because Steam would have exported the tracks and because of the price! P.S. I’ve already seen it resold by several users for much, much less than the purchase price… not good…
Thanks, but idk if this is the right approach. You already posted one doom-and-gloom thread, this isn’t a “shit on the xy and scare people into selling their device” thread. This is the “i believe in the product and see a clear way forward” thread.
i don’t know anything about the inner workings of TE, but if i speculate about it… if you are not happy with the frequency and content of the updates for the XY, the resources needed to support whatever kind of user content made the for the device doesn’t seem like that would be any faster to be provided by the company?
i don’t know if the internal code they have is made with any intention of opening it up to other people to mess with and made additions to it. that seems like a whole other thing entirely to support and put resources towards. and i don’t know code, but wouldn’t that maybe even have to be baked into the infrastructure of the code in the first place, like in the DNA of the device? i can’t imagine them putting in the kind of work that would require over or in addition to the incremental updates they are doing for it now.
from what i can see the “team” is one dude at TE who is in charge of the XY updates. i would be very very surprised if TE allocated more resources in that direction, since its kind of the brain child of one dude. i also don’t see any motivation from their end to open up the device in any way at all, even with the desire to have that done voiced by some of the users?
if TE would open source any of their devices, it might make more “sense” to do that with the original op-1 or the op-z seeing as how both those devices are discontinued. but i have heard first hand that the code on both of those are in no shape to be shared publicly.
Im not happy with the quality and frequency of your posts, so would like to ask that you share your username and password with all of us so we can better represent your thoughts. Thank you.
I like this reply, at least we’re on topic. I agree it’s not probable that they’ve built it from the ground up with making an SDK in mind, which is why developing an SDK is a project in its own. I disagree that it’d have to be ‘baked into the infrastructure’ of the code, i don’t know how versed you are in coding practices but it’s not as complicated as it seems. It’d take the development of some platform guidance (how the inputs/outputs/processing chain works, which language and libraries to use), a tool to compile user-made devices, maybe an emulator for testing wip devices and an import/export method (probably just moving stuff over the normal usb connection to a dedicated “plugins” folder would be enough). That’d be kind of the minimum of what I mean when I say “SDK”.
I feel like it’d be really exciting for every device in the OP series to be open like this, I just suggest the XY because its hardware is superior and it imposes less development limits.
I don’t think TE would be motivated in any way to open things up unless made aware of it - they’re not the open-source kind of developer, but I think it’d be awesome if they were. Everyone should be. And they do listen to the community so it’s important to talk about.
I did hear as well that the SOC the OP1/Z were based on does not support this because of licensing issues, I don’t know about the XY’s hardware and if it shares that problem. I’d need someone with more experience looking into this to explain or gently let me down.
It’s definitely feasible, and you can disagree with me that it’d be a good future for this device/series, but I’m hoping we’re in the timeline where you get to see how wrong you are when they do it.
Here’s another example of the direction issue. The most recent update 1.1.0 has an awesome new feature - a ducking tool! That’s so exciting. However, ducking is far better suited to being a send-based methodology (send channels to a dedicated ducking send) rather than a per-channel tool. I could go into why but that’d take a youtube video to explain. The obvious conclusion due to the way ducking was implemented here is, that to achieve the basic mixing necessity of channel ducking, we would need to sacrifice the modulator slot for each channel we choose to duck. So, a mixing tool is getting in the way of the sound design process - a different creative stage.
This signals one of two future possibilities:
The future of modulators on the XY is that there’ll be several of them per channel, and not only a single slot. This is nice, but not probable, because of hardware limitations.
We’ll just have to live with this problem (not “fun limitation”, just a problem. e.g. I can’t use an LFO on any channel because I’m making [insert loud genre here] and must duck my instruments so that my kick/snare don’t blow out my mix, or I’m making a 4/4 pumping mix and will never be able to use an LFO), and therefore have a less satisfying creative process / more primitive result than would be possible on the instrument.
Videolab for OPZ is proof that they are aware of the potential in user created assets for their machines. They must also be aware of alt firmware and hacks to OG1 along with diy hardware hacks (PO modular etc) which have been encouraged and featured on the company blog/newsletter. As you noted, they take in alot of community feedback and must be aware of the years of chatter on this topic and desires of a vocal group of users who’d love more support for an open platform.
The fact that no progress toward public facing sdk has been made seems like a strong indication that they’d prefer keeping their products in a closed loop with limited changes (they control) via incremental updates. That’s not a sign of ego or ignoring logic, it’s their product and feels a bit unhealthy to wish for a different outcome so forcefully that we start to ignore that TE has a specific vision of their own and the right to determine the future roadmap for these devices.
It seems like you have decent experience with software development so I’m curious, have you tried making your own software-hardware tool instead of adapting someone else’s? That might be easier than convincing an established & rigid company like TE and their fanbase to join you in your attempted quest.
Nobody casts doubt on anyone’s right to the vision of their own product line. But you’ll agree with me that everyone has the right to tell anyone when they think they’re wasting an opportunity. Including myself, a client, telling TE, an org, that they’re potentially wasting an opportunity for greatness. I can respect the fact that they have a beautiful vision while providing valuable feedback and trying to nudge things the way I (and others may) think is good. It’s important we all try our best to dodge the strawman - I’m not out there throwing molotovs and breaking windows. This is all perfectly healthy discourse, aside from some who would love to derail it.
I think the fact that no progress was made on this in the past indicates simply that TE assessed that it isn’t a good direction at one stage, and they can reassess that at any point. There are plenty of DAW’s out there, and plenty of DAWless devices, there’s no reason not to try for a third, genius format.
I do have a lot of experience, but I’m unfortunately not a developer or coder. I wouldn’t be able to make even a distant facsimile of something acceptable with my skillset and I would suffer the whole time doing it, it’s definitely not my thing. Trust me, if this platform were open, just like the ER-301 was in the Eurorack space, I’d be all over trying to customize stuff, and if I were skilled at writing DSP, I’d have made a whole suite.
Fair points and I wish you the best. Contacting TE directly with your feedback seems like the most constructive way to get what you want (rather than posting here) but we’ll see what happens in the future.
I’m glad you mentioned ER-301 since that’s a great real world example of how far an electronic instrument can be driven beyond the original designer’s abilities once a community forms around open platforms
I’m familiar with the power (and occasional frustration) associated with open systems & been a fan of monome norns and critter/guitari organelle. Open tech is always better for my taste but I’ve learned to accept that each company weighs the benefits and some have valid reasons to keep their tools closed
You know another reason why it’s a good mention - Bryan couldn’t keep working on it after Covid ruined everything and he took on consulting jobs and got too busy. So because the firmware and hardware were closed-source, the device support just died out. Forums went down, all development of custom software pretty much fell off except for some stragglers on Facebook and Discord that I’m aware of. So another reason to open things up. It’ll simply extend the life of the device to ‘as long as people still enjoy it’. Scarcity is made up, man. [rips bong]
Synthstrom seems to have paused the “official” firmware for their Deluge at the 4.x branch and are letting the community firmware soar. Amazing what the device can do today even on Community firmware 1.2 compared to loopop’s original YT demo (I think on official fw 2.x?)
But yeah, I think TE might want to keep contributing to their products, and establishing governance to review and accept new features may be out of scope for the moment.
My fear is that the hardware / cpu limitations are so severe that the community would have a hard time adding something more stable than TE has.
There must be a reason they limited something odd as “only 127 notes per pattern”
That being said, my list of (at least seemingly..) low hanging fruit quality of life improvements is getting bigger by the minute - and I own the device only for 48 hours and I’m lucky enough to have the v1.1.0 experience. The community would surely make quick work of that.
As a web developer I am already itching to (and probably will soon) make a custom webapp to control the xy on my ipad avoiding certain finger gymnastics. dedicated controls for muting, switching scenes are just the tip of the iceberg. But oddly enough the midi cc reference table does not include obvious stuff like toggling metronom or changing patterns.
I would have loved to make this more than just a proof of concept and actually usable, but the field does not support midi program changes afaik
like I said in my previous comment, I probably will end up cooking something similar for the xy, primarily offering controls leveraging the midi commands to change scenes, mute tracks etc. - since I already use my field as a controller for the xy, I might also forward the fields outgoing midi to control the xy further.
but all of those midi shenanigans dont even come close to a proper sdk or even opening the OS. also requiring an app as intermediary to control the xy with the field feels unnecessary as te could add an “xy control mode” to the field directly.
so yeah, maybe this time instead of developing in the dark, I start a thread here and ask for ideas before I go to town
I agree with you 100% and think that’s a wonderful idea. I hope you enjoy the xy but I’m mainly sorry that it’s such a tantalizing taste of what’s possible whilst being so severely limited for what it is. Definitely an ambitious undertaking by TE to launch this product, and I believe in it. I just wish I could also contribute. And so can the rest of the community if given the chance.
