Original suggestion by CurseForge user Emerald310

Would you consider adding functionality for the looper block to play/stop the stored music on redstone signal? Not sure if I'm missing something, but I think as it is, you have to manually right click the block to play/pause, and while its playing, you can give it a redstone signal to restart the music. But I don't see any functionality to start/stop the music automatically (via redstone). I just think that would be really cool, since you could create a chime when opening a door, et.c. and many other contraptions I'm sure.

Re:

You are correct to suggest that the current implementation is to reset the music track. The idea behind it is to better sync multiple loopers at once, such that they will start at the same tick - implemented via a redstone clock. Similar to music production "layers".
I do not wish to abandon the idea, and so I think I will therefore divide the redstone input signal as per something like this:

= 15: Plays the recorded sound once
≥ 7.5: Plays the recorded sound indefinitely
< 7.5: Resets the music track

This stems from the idea that one would usually put the button input directly behind a block, giving it a signal of 15 - effectively acting as a doorbell :)

I will also add a shift-tooltip on the looper item to tell of this information.

In my opinion, it would be more logical to flip the =15 and ≥7.5 behavior, as I think it makes sense that if you give it "more power" then it will be able to play more? Just thinking in the logical sense here.
Would appreciate any input!

Hey, glad you like the suggestion.
The textures I used when experimenting with this were actually in game photos from the Exposure mod, taken of 16x16 builds replicating the textures. Pretty funny but it worked.
Anyways, I decided to make some proper sprites, so feel free to use these/edit them to use for the looper block.
Thanks for taking in the idea, take your time implementing it, no worries there.
Here's the spritesheet, and a zip with individual sprites.

looper sprites.zip

Worth noting that I couldn't decide on which off-state sprite I liked better for the loop, so I included both.
Also included an alternate colour scheme for the volume sprites, I personally prefer the "traffic light" style, but keeping it to the blue breaks the palette less, so up to you.

Thanks.

Appreciated! Will keep you posted.

Hi, Emerald here.
Thanks for taking in my suggestion, I'm keen to see this feature in action.

I like the idea for your implementation, I think it would work well. The 15 power signal playing "more" does make sense.

However, with this being right up my alley of interest, I did have other ideas.
Now to be frank, I don't have experience with java, but I can't imagine implementing the following ideas to be easy, but in any case, I hope you can gleam some inspiration for the functionality of the block in future.

So here's my pitch. The design of the looper block is interesting, having the play/pause button right on the front face, acting as a toggle. My central idea, is that if you can pull off changing the functionality of that button, so that instead of right-clicking the block on any face and having it play/pause, you have to right click it specifically on the play/pause face. (let's call that face "forward").
I imagine it being technically possible, since the chiseled bookshelf in vanilla does a similar sort of thing to a degree - but I'm not sure how difficult it would be to implement. Further, a redstone pulse directed into that side of the block could toggle the play/pause, but directed into another side of the block, wouldn't.

Regardless, the point of making that change, would be that it essentially frees up the other faces of the block to have other functionalities.
So then, for example, you could have it so that the right face of the block could have a "looping/not looping" toggle on it. And once again, have the functionality to switch that toggle with a redstone pulse, specifically directed to the face of the block the looper toggle is on.

Another use could be a face with a 'reset' button. As it is, I believe when you pause the looper's music while it's playing, it stores how far into the music it is, so that when you hit play, it resumes from where you left off.
Well if you had a reset button, it could function so that, if the music is currently playing, it starts again from the start on reset pulse (similar to how the looper works currently). But further, this way, you could also reset after pausing, so that instead of resuming where the music was left when paused, it plays from the start of the music again.

And a final idea (because the forward face is play/pause, top face plays the music, bottom face would be on the ground usually and therefore useless, right face could be loop/don't loop, and left could be reset),
I'm not sure if this is even possible with how minecraft works, and you could always have some other kind of functionality on this face instead. But, the back face could be a volume button.
I'd imagine this working by changing the volume of the block depending on the power level of the redstone signal that was last received on this face. E.g. a power of 10 would be the usual volume (100%), a power of 1 would be very quiet (10%), and a power of 15 would be 1.5x louder than usual (150%).
In terms of being able to right-click this face to change it (as each of the previous functional faces would be open to doing too), I think it would make sense to have three states, represented by three textures (rather than 15, yk). So basically a low, medium and high. Maybe right clicking cycles through the volume
values of 50%, 100%, and 150%. Quiet, normal, loud. Also if the volume is set via redstone power to something in between those values, I think rounding the volume to one of the three values to determine which texture to use, (without actually changing the volume) would make sense.

Anyways, I've been toying with this idea for a bit, and ended up visualizing it (really to help myself imagine it clearly). I'm running this mod in a personal modpack with many other mods, including one which let me essentially try out faux custom textures on the looper (via Exposure mod).
So here's what I imagined each functionality looking like,
Loop/Don't loop [img]

Reset [img]

Volume [img]

Faux textures [img]

So yeah, I don't imagine this will all be used or anything, but hopefully it gives you some ideas going forward.
In any case, I'm keen to be able to play/stop the looper block via redstone, regardless of implementation.

Thanks!

That's actually a very neat and detailed idea, thanks for pitchin it in! The visualization is a huge help.

I'll sum up your fancy scroll here:

Your suggestion is to basically make the other faces of the block act as different input signals to change the playing behavior and parameters of the music tracks. I really like this idea, since it gives much more flexibility over the looper. Not only that, but there is also no current way to set the actual volume of the music track. So, nice one!

The faces should indeed derive from different redstone signals:

• Play [Main]: No special behavior
• Volume: 1-15 as a representation of volume percentage, such that for any given r notated as redstone input, the volume will be determined as r / 15.
  0 should just keep its state.
• Loop: A togglable value to determine whether the looper should loop or not. The input redstone value determines the state of the toggle (redstone in -> toggle enabled, no signal -> toggle disabled)
• Reset: Simply resets the track. A redstone trigger that only enables once upon redstone input.

The right click behavior of these faces will perform their respected action, with the volume one in specific increasing and wrapping by 16/3 steps; about 5.

I'm not sure if this is even possible

To that I say, never say never. It has previously been done with the comparator, repeater, furnace; as well as the bookshelves, per se.
I could probably work it out somehow, though I can always resort to simplification nevertheless.

I would appreciate it if you could provide me with the texture spritesheet such that I may utilize it during the development.
Do note that I am yet to start on patch development, so it may take a while before this idea is actually pushed into production.
Thanks again!

I think I have it done!

The problem with Minecraft is that the more states I add (eg, Volume, Looping, Playing, Reset...), the more boolean expressions I need to add to the model JSON. The formula is $2^{n}$ (n being expressions). And, well, $2^{7}=128$...
So, ye.

Another issue is mostly a user-friendly one. We'd usually like to have as little elements and details to a block as possible, and I'm afraid that having so many input signals will cause confusion and even misery to some non-technical players.

So, the solution I came up with is to only implement the looping state;

• The reset and playing signal are now united, such that it is determined via the redstone signal. An input of above 10 will cause it to reset, while below it will cause it to cycle.
  The thought behind this is that mostly more technical players will want to use the cycle behavior as opposed to regular player, so having this single barrier may not be that impactful.
• The volume input could easily be determined before recording, via the Instrument Options. The volume of the instrument is saved inside the looper.

Since we now thus only have a single redstone input, it matters not where we connect a redstone signal - it will always simply cycle the play state.

With that in mind, here is the implementation I stand in now w/ the Beta version:

(this is a vid click on it)

The texture utilized in the looper is yours, so you will of course be credited accordingly upon release.

The usage of the comparator tied to a composer makes a pretty high redstone signal, such that connecting it to a substract comparator produces a low redstone signal - triggering the Play's 2nd behavior of cycle mode.

I'll be closing this issue assuming the implementation is alright. If you believe something should be improved, please do say it!
Many thanks!

Hope you don't mind the comment on a closed issue -
Thanks heaps for all the work put into this feature, I think the implementation you've gone with is good, I think it adds all I could hope for. I'm very much keen to play around with it - I'll be watching for the next release. Thanks!