-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixxx Macros #2873
Mixxx Macros #2873
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes more sense to have a flip control per deck than a single one. This class boilerplate looks like it was inspired by RecordingManager, but IMHO the recording manager is unrelated and you should rather look at CueControl or LoopingControl for inspiration instead.
Instead of introducing boilerplate classes that we might never need we should better focus on finalizing the basic concepts. |
This is the format that Serato uses. It would be cool to use a format that can be made compatible for import/export: https://github.com/Holzhaus/serato-tags/blob/master/docs/serato_markers2.md#subentries-of-flip-entries |
I can't tell if this is an appropriate structure because it doesn't do anything and I don't know what it's planned to do. I'm not sure if this class is needed, and if it would be needed, why it would need access to the UserSettings. |
@uklotzde I am not quite sure how these types are supposed to inspire me. |
I don't see a use case for Macro recording controls for each deck - you are not gonna record multiple macros in parallel anyways. |
I think it makes sense because then it's all bound to a deck. It shouldn't be possible to record a macro and then save it to a slot of a different deck. |
I didn't wrap my head around the macro concept too much, but it make sense to have the respective controls as close as possible to the deck they're bound to. |
This won't be possible - it remembers which deck it recorded on and will save it to that. Please tell me a use-case where this way would improve it. How are we supposed to map the recording button if there is no single general Macro recording control? Also, it would clutter the UI. |
The mockup above is almost exactly how Serato does it. Where this Row goes might change, but I'm pretty sure there is no benefit of having multiple such rows. I don't want to discuss about what's technically architecturally "correct", I want to find a solution that makes sense. And as far as I have seen, an architecture similar to the RecordingManager does make sense for the recording part. |
Let's continue this discussion in Zulip and don't forget that I have already written a specification for the controls. |
It works! Here's how to use it for now:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Didn't have time to test it yet, but here are some first comments.
src/recording/macromanager.h
Outdated
#define MAX_MACRO_SIZE 1000 | ||
#define NO_DECK nullptr | ||
|
||
struct MacroAction { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that important for now, but please use classes for stuff that isn't in the anonymous name space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add that to the coding guidelines in the wiki? I wanted to know your policy for structs but didn't find any.
Isn't this the exact use case struts where meant for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In C, yes. In C++, structs are just regular classes with default member visibility public instead of private.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but default visibility public is appropriate here, or not? They are almost plain data structures.
Also, please document in https://github.com/mixxxdj/mixxx/wiki/coding_guidelines
Theoretically you are right about how everything should be atomic, but I can't envision a use case where it would actually make a difference, so can't we simply avoid that overhead? |
No. |
Code as if the worst case scenario is happening all the time, because it will happen sometimes. |
I'm unable to build this:
|
After adding a closing brace manually, compilation works but I'm getting a bunch of linker errors:
|
@xerus2000 We don't want broken commits in our history, so please fix them. My workflow for this is committing the fixes as small atomic commits, then rebase and copy each line with a fixing commit directly behind it's corresponding broken commit and replace |
Yeah, I usually watch out for this as well. It built fine for me, but I'll check again. |
Yeah, messed up the CMakeList again and didn't notice it due to cache. I fixed it in an extra commit - because of the merge rebasing didn't work properly. |
Co-Authored-By: Uwe Klotz <uklotz@mixxx.org>
src/macros/macrorecorder.cpp
Outdated
auto armed = MacroState::Armed; | ||
// TODO(xerus) add concurrency test | ||
while (!m_macroRecordingState.compare_exchange_weak(armed, MacroState::Disabled)) | ||
QThread::yieldCurrentThread(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we need to reset the recording state to armed to ensure that the macro has been fully written, you should just use SPSCQueue instead.
@xerus2000 ping.
For Library & MacroRecorder the public definition of their config/control group key was removed and replaced by an entry in the anonymous namespace in the cpp file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far, thanks!
Remove all mutability functionality which was previously needed for recording, instead the Macro class is now used for playback.
Woops. Well, we can start with a blank slate then. |
Huh? Why did you close this? |
Accidentally deleted the branch ^^ |
For now only to get early feedback whether the file structure & initialization code is correct - no actual functionality.