Skip to content
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

Allow different playback modes for samplers #5883

Open
mixxxbot opened this issue Aug 22, 2022 · 20 comments
Open

Allow different playback modes for samplers #5883

mixxxbot opened this issue Aug 22, 2022 · 20 comments

Comments

@mixxxbot
Copy link
Collaborator

Reported by: esbrandt
Date: 2011-05-01T11:18:43Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp774808
Tags: looping, sampler
Attachments: playmodes.patch, playmodes.patch


  1. Normal mode : Play from start to end and stop. Pressing play again stops the sample.
  2. Repeat Mode: Play from start to end and repeat. Pressing play again stops the sample.
  3. "One shot" mode (its like hotcue_X_goto): Play from start to end and stop. Pressing play again starts the sample again . Use left button to break the loop and stop the sample.
  4. “Note off” mode (its like for stopped hotcues): Play from start while button is down and stop upon release
@mixxxbot
Copy link
Collaborator Author

Commented by: rryan
Date: 2011-09-30T22:22:21Z


need to make the call on whether this will go in 1.10 or not. we shouldn't release samplers to the world half-baked but at the same time this shouldn't blcok the release

@mixxxbot
Copy link
Collaborator Author

Commented by: rryan
Date: 2011-12-04T23:06:14Z


I think we should nail down the sampler use case in 1.11

@mixxxbot
Copy link
Collaborator Author

Commented by: rryan
Date: 2011-12-04T23:06:34Z


For now it's kind of the "minimum viable feature".

@mixxxbot
Copy link
Collaborator Author

Commented by: rryan
Date: 2012-03-28T04:51:05Z


AFAIK not happening in 1.11

@mixxxbot
Copy link
Collaborator Author

Commented by: marco-a-simao
Date: 2012-08-01T16:54:11Z


I dont think this is the correct description of the bug. AFAIK at 1.10 there is only one play mode: sample plays from start to end, pressing play again doesnt replay it. Am i missing something?

@mixxxbot
Copy link
Collaborator Author

Commented by: r0w4nj
Date: 2013-05-03T13:10:23Z


I've fixed this bug and implemented each of the modes... How do you think the mode switching should be done on the GUI?

  1. right click the play button to toggle modes
  2. separate button to toggle modes
  3. something I have't thought of!

As for now Ive added a button using the 4 hot cue number button .pngs to toggle between modes...

I will link my brach shortly.

@mixxxbot
Copy link
Collaborator Author

Commented by: marco-a-simao
Date: 2013-05-03T14:14:25Z


We could have a single button that updates its png like: 1, 2, 3, 4 corresponding its modes, what do you think?

@mixxxbot
Copy link
Collaborator Author

Commented by: r0w4nj
Date: 2013-05-03T14:23:37Z


Do you mean a play button that changes its png or separate button?

@mixxxbot
Copy link
Collaborator Author

Commented by: marco-a-simao
Date: 2013-05-03T14:52:05Z


I thought separate button, but your suggestion "play button that changes" seems more pratical better solution ;)

@mixxxbot
Copy link
Collaborator Author

Commented by: r0w4nj
Date: 2013-05-03T15:07:29Z


here's my branch:

lp:~r0w4nj/mixxx/rowanstrunk

The 4 modes I have implemented are:

  1. Normal Mode - Same as before (play / pause) except now jumps back to start when reaching end of sample.

  2. One Shot Mode - As described in the bug description.

  3. Hold Mode - Pauses on release, plays from same position on press.

  4. Note off Mode - As described in bug desc. same as hot cues.

There is already a dedicated repeat button so no need for a repeat play mode as per bug desc.

I have only the first sampler changed the Deere 1280x1024 .xml to support this as of yet to see what people think about how to design the gui.

@mixxxbot
Copy link
Collaborator Author

Commented by: r0w4nj
Date: 2013-05-03T15:08:43Z


Cool, yeah I've implemented a seperate button you should check out my branch and see what you think :)

@mixxxbot
Copy link
Collaborator Author

Commented by: marco-a-simao
Date: 2013-05-03T18:03:06Z


I will try it tonight as im not with my notebook right now, but great solution im looking forward to see it ;)

@mixxxbot
Copy link
Collaborator Author

Commented by: marco-a-simao
Date: 2013-05-03T18:04:22Z


Are you open to other modifications? Could we too try to implement effects unit? I tested lv2 plugins with jackd and they very cool and stable, maybe we could adapt something, all projects using it, use c / c++ and qt as well ;)

@mixxxbot
Copy link
Collaborator Author

Commented by: r0w4nj
Date: 2013-05-03T18:46:29Z


Definitely, I'd really like to work on effects integration. I haven't worked with lv2 before but it looks great :) This depends on the result of my GSOC application though as if I'm accepted I will be spending the summer implementing a loop recorder!

@mixxxbot
Copy link
Collaborator Author

Commented by: esbrandt
Date: 2013-05-04T07:18:55Z


Nice one Rowen.
Had the chance to test your branch and would like to give some feedback.

  • The fact that samplers now jumps back to start when reaching end of sample is a good touch, and i can see it being the standard on the regular decks as well.

  • The multi-state button to indicate the samplers playback mode is fine. With the sampler decks there is always little space and we use multi-state buttons already in other places. Also, dont waste time on the buttons look, we'll take care of that later.

  • The existing Repat control seems ok for now, but works only if we play a sample to it's end. If we'd further extend the sampler functionality, like starting from an Cue or Loop-In point and stopping at Loop-Out, then we'll need a new state for the play_mode control. Another thing it would be come handy is when we start playback in a predefined loop-size (loops and loop resize controls work in samplers too).

  • Integrating the new "play_mode" control into src/skin/tooltips.cpp and /src/controllers/dlgcontrollerlearning.cpp would be beneficial. This allows to display the buttons tooltips in the skins and to assign buttons on external MIDI devices to the control.

  • There is a flaw when a sample is playing and and you change the playback mode in between: Set playback mode to [ 2 ] ans start playing. While playing, set playback mode to [ 3 ] or [ 4 ] and click the play button again. The play buttons changes to it's inactive state even if the sample is still playing. Then, if the sample reaches the end, it does not jump back to start.

Good work so far, thanks

@mixxxbot
Copy link
Collaborator Author

Commented by: r0w4nj
Date: 2013-05-05T08:03:28Z


Thanks for the feedback Jus :)

  • Yes - The only problem I could see including this on the decks would be if scratching a sample at the end of a track and it jumping back to the start.

  • Great I'll just leave the 4-state numbered button for now then. The 'Sync" button could be made much smaller to make more space...

  • I'll look in to ways of implementing this. It might work well if the current 4 play modes worked with a loop-in/loop-out point and treated them as the start/end of the sample.

  • I'll get cracking on this.

  • Yes, I was aware of this, I just didn't want to spend time fixing the problem until I had some feedback on whether my overall approach seemed ok! I will sort it now though. I need to test this with midi too (once I've integrated it), to check from problems that may occur switching modes while pressing the play button on keyboard / play pad etc on the controller.

@mixxxbot
Copy link
Collaborator Author

Commented by: r0w4nj
Date: 2013-05-07T20:12:05Z


I've now completed the following and updated my branch:

  • Added tooltips to src/skin/tooltips.cpp
  • Fixed switching modes problem
  • Updated /src/controllers/dlgcontrollerlearning.cpp

I had to create another push button within EngineBuffer for the MIDI control as mapping directly to the play button caused toggling issues. I've tested this with an MPK-mini (momentary mode: pad press = 1 pad release = 0) and everything seems ok :)

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2013-05-07T23:07:48Z


There seem to be a lot of changes in your branch that aren't related directly to this bug -- can you create a patch that would apply cleanly to trunk that just has the bugfix?

@mixxxbot
Copy link
Collaborator Author

Commented by: r0w4nj
Date: 2013-05-08T10:38:55Z
Attachments: playmodes.patch


Here's a patch for the trunk.

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2017-05-26T06:43:45Z


Considering the last activity on this was in 2013, I'm changing this from In Progress to Confirmed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant