Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Comments
Yes it’s work properly, that’s great and magical.
I will try this with other cases and let you know the result. I hope it works .
Thanks wim .🙏
It's a hack, and may not work if you move the knob too quickly. You'll want to test rapid changes right around the top of the knob travel to be sure it's not resetting to the default during normal movement.
@pejman : keep in mind that this method won’t work if the knob is already at 64 when you double-tap.
It is working very well. I tried it at different speeds and with different accuracy. It works without any problems.
I just have to try it with combination with ( random knob position ), with Lfo SH type And with different rate , the same thing we talked about before.
That's right.
It's a hack. I don't like hacks. I'll probably wish I hadn't posted that.
But it works. I adjust knob to value 64 and then double tap: results are ok . If that's what you mean.
Hacks can be good … sometimes 99% effective is better than no solution! Yours is a good one. And there is probably a solution for the case I mentioned if it rears its head.
Can you please tell me more precisely what you mean?
The only issue is that when I set it to a number other than 64 and play double tap, the value number in the status bar in mozaic shows 64.
It will work the first time you double-tap it after uploading the script. But if the knob is at 64 after that, it won't work on a double-tap. The difference between where the knob is and 64 has to be more than one. It will work if the knob is at less than 63 or more than 65.
You should probably change
(Abs (64-lastValue) > 1)
to(Abs (64-lastValue) >= 1)
. It won't fix that issue but makes a little more sense.That number is always the internal position of the knob as moved by your finger, not what it represents in your script. Ignore it. Label the knob with its value according to your script.
Ok, Thank you very much, I put it in patch ( change ).
But it works .
Can I ask you to explain to me step by step what you mean so that I can understand it.
Maybe if value and last value are 64, one can treat it as a double-tap, too.
(Abs (64-lastValue) >= 1)
comparison fails.“@OnKnobChange
set = GetKnobValue 0
if set = 64
SetKnobValue 0, 90
endif
@end”
This also works fine if I don't put the , Round before GetKnobvalue.
That will work on double-tap, but you will never be able to set the knob to 64. Maybe you don't care?
If you're sending midi values, don't forget to
Round
before sending as a midi value. Otherwise you'll be trying to send decimal values via midi, and that isn't allowed.[edit] though it's possible that Mozaic tidies that up before sending it out. I haven't tested.
i am pretty sure Mozaic will convert to integer even if you give it a float.
yeh, thought of that after I posted. Still, that's sloppy and presumes it will always work that way and not get "fixed" or broken later on. Not a good way to code.
If you want to 64 to be an allowable value I think you want something like
If (value =64) and (previousValue=64)
That way you can still turn the knob to 64.
@wim, @espiegel124, @pejman
The double tap detection by comparison with 64 works because GetKnobValue returns a float for the position - and it is extremly unlikely to manually move the knob to 64.0000
There is no problem at all to still use/dial in the center value if the ‚equals 64‘ case is handled first and the rounding to integers of the GetKnobValue happens after that check:
Even if you really, really carefull move the knob to the center (and get the DoubleTap detected message and SetKnobValue respositions the knob temporary) you will still likely continue to move the knob and this then immediately changes the value and position back to where you were in the value range.
Another tip: If the action that needs to happen on knob change is more ‚heavy‘ (like redrawing other knobs, pads, comuptation etc) it is advised to do that action on real changes of the resulting active value and not on every OnKnobChange call. With the floats as return value and if only using a smaller number of possible active values, it is very likely that several knob positions during a movement will map to the same active value - re-doing that computations or gui redraws.
In the above script, the pad is redrawn on every OnKnobValue, but the knob only redraws on changes of the ‚active‘ value the knob was supposed to control.
.
The knob double tap detection is also described on the Mozaic Tips & Tricks wiki page
Sorry for late ,wim and espiegel.
Yes your right. There is this problem with your patch too : when i load your code ( about set knob with double tap ) or my code which you can see in this post, and load them, And I turn the knob slowly with my finger ( before doing double tap ) so that I pass it from 64, In forward or reverse mode, the knob instantly jumps to the value I gave it with the
SetKnob
command.But here is the interesting thing, that when I double tap for the first time after loading the your patch or my code , the problem ( instantly jumps to the Setvalue ) goes away. And it is a question for me how this happens ???
In fact, this is not a problem for me because my goal is to save time to set a knob to a specific number, by using double tap. Instead of trying hard to adjust the knob to a specific number with my fingers, When I want to reset the knob to a specific number at certain moments while working with the patch.
@ki,@wim,@espiegel.
A very interesting new discovery.
I was able to make an interesting discovery through the patch that ki designed.
However, I found the answer to my question in the previous post, so the problem is something else.
You know that you cannot reach the integer 64.0000 simply by moving your finger on the knob
But if :
1, Move the knob with your finger to the value 127, that is, to the end of the knob and fixed it.
2, Separate your finger from the screen. ( important ).
3, again touch the knob and move knob , Very soft and very slowly ,from 127 to 64.
Result : value = 64.0000, ( This number is well displayed in the PAD designed by Ki in its patch ) , and knob jump to the set value which we have already determined. in the lower pad appears the Detect mark.
But if you try this steps with value 0 in first step , You can't get the number 64,0000 at all.
So I got the answer to my question that I asked in the previous post, that even after double tapping this problem can occur if the steps I mentioned above happen.
I try it by sending midi cc , its ok without problem , even with Translatscale .
As you can see in the picture. I took a screenshot of Knob moving. Please note my patch codes too.
@pejman I tried your method to dial in exactly 64 with my script sample, but on my iPad Pro 10.5 i only got as near as 64.1077
I suspect that screen resolution and pixelwidth of Mozaic UI could play a role in that case. I tried in standalone and as plugin in AUM with several UI sizes and also in portrait mode, but wasn‘t able to reach the 64.
Some more test later…
Yay - i installed Mozaic on my iPhone X and there the knob value changed in 0.2 steps on movement for the Mozaic standalone in landscape mode. So after several tries, i was able to reach 64.00 without double tap, both starting from the 0 or from the 127 position.
I then had a look at the different minimal values i get on my devices, the very first value above 0 on minimal movement which seems to be the increment value for the current UI width:
Thanks for that insight, i didn‘t know about the UI width dependency of the possible knob float values 👍🏼
=> It would be cool to know which devices are also able to manually dial in 64.0. So i would be happy if other users with iPad Mini, iPad 10, iPad 12 and Phone would post their minimal value. Worst case would be that the assumption „one can‘t dial in 64.000 manually„ only holds on the crude resolution of the iPad Pro 10.5…
.
TLDR: On my iPad 10.5 i wasn‘t able to manually dial in 64.0, but it turned out to depend on UI width. The iPhone X landscape resolution allows to manually dial in exactly 64.
Yes it depends to resolution or pixel width UI mozaic.
I have ipad air 2 9,7 inch. I got screenshots in different size.
Thank you for putting these Tips and Tricks together. What you accomplished with the graphics in
“AUM Transport Control” is truly epic for pushing the envelope of what’s possible:
I have problem with mozaic in standalone mode in background mode. When mozaic is in background for a 15 or 20 or more minutes , And when I come back to it again, I get this message. So far several times I have lost the code I was writing.
Have you ever had a similar problem? Is this normal ?
Should I report it as a bug to Brambos ?
Ipadair 2 ios 15,7,4
?
Mozaic isn’t intended to run standalone. If you do then always save when putting it in the background.