Thank you, @Slak_Jaw , for your response email today, which helps us understand your perspective. I also appreciate your proactive approach in compiling a top 10 list.
I have two points regarding this:
I believe it’s important to agree on the main categories if improvement as a foundation, but ultimately, we should vote on specific change requests. This ensures clarity for everyone involved.
More importantly, before we proceed with such an approach (and all invest time into it), it’s crucial for me to be confident that there is genuine commitment, capacity, and time available from the development team to actively work on these changes—and that we will receive a proper feedback loop. The current process, where suggestions are often met with “I’ll pass it through to development” but we hear nothing further, is not sufficient. This would require a different workflow and mindset, and I’m unsure if Algoriddim is truly ready for that.
Additionally, even if we reach an agreement on changes, it’s vital that these changes are implemented within a reasonable timeframe (short- to mid-term, say within 18 months). If implementation takes too long, attention and engagement will inevitably wane, and other priorities will take over for everyone involved.
Without firm commitment from Algoriddim management and a clear timeline for implementation, I fear this initiative could end up being a significant disappointment for many interested, loyal, and dedicated users.
@Michael_Android mentioned in his response that he’s willing to volunteer his time to help facilitate this process, but also he emphasized the need for commitment before proceeding. And rightly so, in my opinion. Based on what’s needed here, the overall timeline would likely take at least a year, if not more, according to my cautious estimate.
@DJ_Big_Blender, thanks for your thoughtful input and for your dedication to improving djay. Your passion and ideas are evident, and we truly value the time you’ve taken to share them.
We understand your desire for clear timelines and a strong feedback loop. While we aim to be as transparent and aligned with user requests as possible, the complexities of software development, including dependencies on 3rd party services or devices, can make it challenging to commit to fixed timelines or guarantees. Our process must remain flexible to account for feasibility and to adapt to technological advancements.
That said, we carefully consider every piece of feedback and incorporate them into our planning. Initiatives like compiling a Top 10 feature list are incredibly valuable for helping us identify user priorities. While we may not always provide frequent updates on individual suggestions, rest assured that your input informs our roadmap and is taken very seriously by our team.
Thank you for your continued support and thoughtful engagement in the djay community. Your input is helping us shape an even better experience for DJs everywhere.
Personally, I would be satisfied with having library management similar to that of Rekordbox and having the possibility of transferring my playlists to a USB stick as I do with Rekordbox and then using them on CDJs.
It’s been so long that I can’t remember the last time I used my MacBook in the evening. Nowadays I only go out with headphones and USB sticks to go partying.
Yes. I would be willing to pay more to have these two things of fundamental importance to me.
I suppose this is an example of how the lack of information about what they are actually working on has led to me assuming they are ignoring it. A list of things that are currently “under active development” would really help.
Jut my 3 cents here. I used to run a software development company for 7 years, and then I managed a big software project for 3 years. I am familiar with most of the procedures and challenges of software development. I know more/less what can be asked from programmers and what is not tangible (like restructuring old database based on new variables). Those details you need to work out yourself, but I understand that sometimes, something is simply not worth implementing (due to time required for reprogramming of such database).
That is why, even if we create a short list of hot topics (like above) and vote on particular parts of it, ultimately, it will be up to your (DEV team) decision to tell us what could be implemented and when. Because only you can estimate complexity of changes in your code.
I hope others will understand this, that even most required things from us could be problematic to develop or even declined by you. And people need to be cool with that. You have a business to run. We can ask, but it’s not guaranteed we will receive it. Even with good intentions of both sides. Just to prevent disappointment or rage from some people that this and that cannot be done. It all boils down to time and money. SO let’s make a realistic list and work with what we can change in reasonable time budget.
What I am trying to say, it’s important to make detailed list that are actually achievable, let’s say within a year (as suggested by @DJ_Big_Blender )
How I suggest approaching it:
Create a short list
Determine detailed functionality per item from such list
Create estimation what can be done and what is not worth to be done (due to complexity or time)
Vote what needs to be done first based on (time and complexity) estimation list.
Start developing and maintain feedback with focus team to ensure correct implementation
I hope it all makes sense. We all need to manage our expectations and be understanding to DEV team.
From personal experience, I also completely understand that software development is far from simple. So I fully agree with your proposed structured approach and the importance of managing expectations. Transparency and realistic planning are key.
It’s crucial that this doesn’t become a ‘push and pray’ approach, where we merely hope that development will find the time and that things will work out.
However, this must be a joint effort, not one that stops at Algoriddim Customer Support. I know @Slak_Jaw works hard, but he cannot manage expectations or meet them alone. Without direct involvement from the Development Team, it risks becoming a disappointment. We need Development in the loop.
More frequent, but smaller, releases could also help maintain a positive connection with users by showing consistent progress. Additionally, there should always be capacity to resolve bugs within 1–2 releases, as some have been open for years now.
For bugs that cannot be resolved or would require disproportionate development time, a “known bugs” list would be invaluable. This would set clear expectations, help users understand the limitations, and prevent them from submitting the same issues repeatedly.
Thank you for your thoughtful input—it aligns well with the collaborative mindset we need to make this work!
Thanks for the additional feedback, @Michael_Android and @DJ_Big_Blender. This is very helpful! Before I reach out to the dev team, I want to make sure I fully understand your recent comments and overall proposal. It sounds to me like users are willing to put in some time to develop a short list if the dev team is willing to provide further feedback on feasibility. Here’s a summary of the suggested process:
Community users will compile a short list of the most important core features or bugs they’d like Algoriddim to focus on in 2025.
Community users will help define the detailed functionality for each item on the list to clearly communicate user goals to the dev team.
The completed list will be shared with the dev team for review. They will assess feasibility for 2025, ruling out items that aren’t achievable, and share a revised list with the Community.
Users will then vote on the remaining items to determine which are most important to them.
The prioritized list will be shared again with the devs, who will adjust priorities further based on timing, complexity, and other factors.
When possible, the dev team will aim to provide regular updates on the status of these items to keep users informed of progress.
This process will help set clear expectations while encouraging collaboration between users and the dev team.
Does this approach reflect what you were envisioning? Let me know if there’s anything missing or unclear before I move forward. I hope that helps!
The features are irrelevant now, we can all blend, scratch, mix and transition… what more is there to finesse?
The thing that I want is stability! I can’t have the decks crash half way through a set, I don’t want “we can’t find that track” at 1 in the morning, I want the intergration that I have with Tidal, Spotify, iTunes, BeatTrack etc to be there every day, not one system one day then another another day, you build your playlist on Tidal and then you’re told Tidal doesn’t work any more so you have to use Spotify.
As far as I am concerned we have paid for the system to be perfected… if it isn’t then fix it… don’t ask for more money “so we can make it right now”.
Algoriddim don’t run the streaming providers! Any failures of those services is out of their control.
It’s also out of your control if you rely totally on streaming services to provide music. It’s up to you to ensure you have a collection of your own PURCHASED music stored locally to enable you to complete any bookings you undertake.
Spotify is not an option. They withdrew from DJ streaming in 2020.
Up till Spotify was invented I had all my music on a plug in Hard Drive, it was because of the Spotify integration that I stopped collecting my music and relying on streaming, I regret that because I had some music that didn’t end up on Spotify. (I’ve been using DJay since 2014.)
I am perfectly happy that I am the DJ… the brain behind what track is played…
My concern is not with the music… it is when the application crashes mid set… which it has done twice to me over the past 20 years… once is once too often.
@DJ_Big_Blender _ Apparently we are both crazy enough to compile such a list? Are you in? Let me know. I would focus on 10-12 max items (considering few of them could be rejected). I think It’s better to have smaller list with bigger development possibility rather that big list with long waiting time. I would be happy to end up with 5 strong items.
You took the words right out of my mouth. I think all software bar non used regularly over a period of 20 years will have a couple of crash issues. New software releases, new feature sets and bugs etc. djay pro is very stable, has been for me anyway, but there will always be room for improvements.
Ideally, everyone in this thread could propose items for the list, but I think you and DJ Big Blender have been the most active in this discussion. So, I think it would be great if you both took the lead and initiative here. Obviously, I’m available to support in any way I can as well. Plus, I suspect at least one of the items on this list could be from a topic I created before I joined Algoriddim
