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 Store

Loopy Pro is your all-in-one musical toolkit. Try it for free today.

MOZAIC - Create your own AU MIDI plugins - OUT NOW!

1959698100101105

Comments

  • edited October 2023

    Here it is being used inside Drambo. Btw, there is also a Drambo module on patchstorage for this.

  • Thanks!!!!!

  • @Synthi said:

    Thanks!!!!!

    Cheers. I hope you find it easy to use. Just ask here if there are any issues.

    I see I was rather brief in this thread when mentioning the patch. Just for reference I add this short quote from the help to accompany the above video.

    "Melody harmonization in the Tintinnabuli style developed by Arvo Pärt.

    ▫️Tap the pads to define a chord, or send in a chord on MIDI channel 16. The harmonizing T-voice uses notes from this chord only.
    ▫️Send in MIDI on any channel other than 16. This is the melody M-voice that will be harmonized."

  • @bleep Wow totaly mesmerizing stuff. Very cool.

    Was hoping to run that session as in the video. But I am not Drambo savy enough...
    Drambo prompted me to save the download as a rack. And then I lost track.

  • Ah, but maybe try the Mozaic download in AUM instead?

    If you want to have another go in Drambo, then you should find the downloaded module like this:

    Then just add your favorite audio unit instrument, and check that the connections are like this (tap on the midi icons). You can delete the miditocv (drag it down).

  • @bleep

    Thank you so much for the maps to put me back on track in Drambo. The ease and familiarity keeps me in Aum to much. Time to play more with Drambo...

  • Hi,
    I haven’t AUM and drambo apps .

    1, Can we access the All 16 pads and shift button of the mozaic as AU parameters through the drambo module ?

    2, If so, can Drumbo show the position of each knob in the mozaic in an updated form, that is, if we have created knobs in different sets of positions in different layers of the mozaic as knobs banks, will Drumbo update it visually in its own knobs. and change or display them ?

    3, Can Drambo be a good app for handling mozaic pads and knobs or AUM ? as AU3 parameters handling of mozaic .

  • In Drambo you get this as Mozaic AU parameters: 16 pads, 22 knobs, XY, 8 user-defined parameters.

    You get them as Drambo knobs with generic names, like Knob 0, Knob 1, Knob 2. These will move in sync with what you move inside the Mozaic UI. In Drambo you can create extra knobs with names that better show their intent. These will unfortunately not move when Mozaic UI is used.

  • @bleep

    Thanks for quick reply.
    But it is still unclear to me

    I have created script , that when i press shift button , The position of each knob changes compared to the previous one, which I call the layers of knobs,

    If I press the shift button in the drambo that is synced with the mozaic, will the position of each knobs change individually in the Drumbo in the column you showed me?

  • edited October 2023

    Shift is not an available AU parameter. You could probably make this work with one of the 8 user-defined parameters; map "User 0" parameter to get that as a knob in Drambo, create a Shift button in Drambo that affects this knob. Then on the Mozaic side you would need to handle a change in "User 0" value and turn this into a Shift pressed event. I guess the knobs will then update in Mozaic, and so the mapped knobs in Drambo would reflect this, too. Haven't tried, though.

    Still, the "Mozaic knobs" column in the picture (if you were referring to that one) will not update positions, only the knobs with generic names will.

  • @bleep

    GREAT 🙏

    Very thanks for explanation .

    Sorry, i forgot to write one of my questions in the previous post.

    To control mozaic pads through drambo, will we have pads inside drambo and is there a velocity pad in drambo like mozaic pads? And if so, can the pads be labeled?

  • edited October 2023

    Velocity is part of a midi note. The bottom pads in Drambo are midi note triggers, they can be velocity sensitive. Your script could listen for midi note in, pick up the velocity from that, and connect the Mozaic pad with the incoming midi note. I do that in the latest script I uploaded (the one you see recently in this thread).

    In Drambo the pads are labeled with note names. I don't think you can change that (?), unlike the track pads that you can name. You could set up a Buttons module with named pads, but you would need to do more to make this velocity dependent, not sure how to best do that.

  • @bleep

    That’s great, thanks for information and help ,.🙏

  • I have a problem with mozaic in cubasis 2 and 3 .

    Scripts that contain lfos , are active when the mozaic window ( UI ) is open in cubasis, and when we close the mozaic window in cubasis ( But at the same time, the mozaic is on and I did not turn it off, the lfos are disabled and their output stops.

    I use for example lfo’s patch by Orchid .

    There’s no this problem in Auria pro .

    Is this a bug in mozaic related to cubasis or is it a bug from cubasis itself and who should this bug be reported to?

  • edited October 2023

    I just found out that this bug is related to cubasis itself, which applies to all midi effects.
    that I have to report this issue to cubasis Group.

  • @_ki
    @espiegel123

    @_ki said:
    @pejman All Mozaic variables are defined globally and there is a limit of around 250 possible variable names.

    A simple trick to overcome the limitation is to change the code to use different array indices of a single variable instead of independant variable names. So instead of

    a = 20
    b = 30
    c = a+b
    SetKnobValue 0,c
    

    Usage a single variable and different indices for all three of them:

    single_var[0] = 20
    single_var[1]  = 30
    single_var[2]  = single_var[0] + single_var[0]
    SetKnobValue 0, single_var[2]
    

    One probabbly needs to add comemnts describing what each of the indices is supposed to contain/do. And i also would add a debug function printing out the current values, like

    @DebugSingleVar
      Log {single_var  [0]:A =}, single_var[0], {   [1]:B = }, single_var[1],{   [2]:C=}, single_var[2]
    @End
    

    that will aid in debugging and can be called whenever needed . In that way, one can use up to 250*1024 variables (states) but the code is unreadable and kind of obfusicated.

    .

    Another thing i often do is re-use of variable names. My local variables names usually start with an underscore. I don‘t assume hat these persist between functions. So if i used a _tmp variable in one of the functions, i can re-use that name for function local computations in another function. _i, _pad, _knob, _val are common names that for re-usage.

    Applying naming conventions is kind of a helpfull mind-set used while programming - one can assign different naming schems for different intended use-cases of variables even though Mozaic treats all of them the same.

    My Mozaic language highlighter for Textastic shows different text styles for different groups of variable names. Conforming to this naming schemes this is quite helpfull for readability and debugging as it visually expresses the intended use-case (_local, CONSTANT, gGobal, pParamter for sub functions):

    ki wrote: “Another thing i often do is re-use of variable names. My local variables names usually start with an underscore. I don‘t assume hat these persist between functions. So if i used a _tmp variable in one of the functions, i can re-use that name for function local computations in another function. _i, _pad, _knob, _val are common names that for re-usage. “

    🔺I do not understand this sentence very well ( “_ I don‘t assume hat these persist between functions.” )_

    🔺 Do you mean that, if we don't put underscore before the pad for example, and use it in two different event or Function in the mozaic, the mozaic will number it as two variables?

    That’s mean

    @onshiftdown

    pad = 64

    _pad = 64

    @End

    @onpaddown

    pad = chann

    _pad = chann

    @end

    pad is calculated as two variables ?

    and

    _pad is calculated as 1 variable ?

    And another important question I have is whether the large number of variables has an effect on CPU consumption ?

  • @pejman: ki is describing conventions he uses. Mozaic knows nothing about them. The underscore has no special meaning to Mozaic . ki uses them to remind himself which variables he uses globally and which he uses locally.

    All variables in mozaic are global.

  • @pejman

    I do not understand this sentence very well ( “_ I don‘t assume hat these persist between functions.” )_

    Persistance means that the value of a variable stays between function calls. All Mozaic variables are global and therefore are available with their last assigned value in all functions - all variables are persistant.

    In many programming languages, there is the concept of variable scope - ie a variable/name is only valid inside a function, or even only valid inside a single codeblock (like the then part of an if-then-else block), depending on where it was declared. After the function ended (or the codeblock is done), the variable no longer exist and can‘t be accessed any more.

    So in Mozaic, marking a variable with _ as first letter is used as hint that one will use the variable as-if-it-was-a-local-variable (which don‘t exists in Mozaic) that will not cary over a value from function to function. Just imaginary.

    .

    Do you mean that, if we don't put underscore before the pad for example, and use it in two different event or Function in the mozaic, the mozaic will number it as two variables?

    No.

    In your example code, both pad and _pad count as a single variable, both used in two functions.

    I meant that using a _ at the start of a variable name is a naming-convention to remind oneself that this variable is meant to be used as local variable. In each function using that variable-name, there needs to be an initial assignment before any usage.

    .

    And another important question I have is whether the large number of variables has an effect on CPU consumption ?

    No, the number of variable definition doesn‘t have an influence in the Mozaic.

  • @ki
    @espiegel123

    Very thanks for simple explanation.

    I now fully understand that there is no such thing as local variables in Mozaic.

    When is it necessary to create local visuals for oneself? That is, in what cases such a work is needed.?
    That is, what variables do you visually and imaginary call local variables.?

  • wimwim
    edited December 2023

    @pejman - I don't think I understand your question, but I have one advice to offer.

    When I have for loops and other routines that use counters, I always get a little bit nervous that I might write to a variable that will get used somewhere else and end up having an unexpected result.

    For instance, if I use a variable called pad to do things like label the pad, and also perhaps to do something like play a note from that pad, I want to be sure I use different variables. Otherwise, in one place in the code I might set pad = 3 but then make a for loop with for pad = 0 to 15. When I get done with the for loop, pad will equal 15 but I might still be expecting it to be 3 elsewhere in the code.

    So, unless I'm seriously running out of variables, I err on the side of caution and try not to use the same variable name for different purposes. There are many cases where it makes sense to do that, but since all variables are global, you have to be very aware of that.

    I don't know if that comes anywhere near to your question, but I thought I'd mention this since I've been caught by it a few times.

  • @wim
    Hi .
    By the way, this was very important to me too, and I needed a lot to be sure about it, thank you for informing it.

    I completely understand @ki explanation about andrascore ( _ ), what he uses them for, and that it is an imaginary punctuation. But now my question is, in what cases do you mark some variables with underscore, for example, you mark them as imaginary local variables.?

  • @pejman : are you asking when people use underscore or how do they decide that a variable is safe to use as if it were a local variable?

  • @espiegel123

    @espiegel123 said:
    @pejman : are you asking when people use underscore or how do they decide that a variable is safe to use as if it were a local variable?

    Hi.
    Exactly both are my questions.

  • @pejman said:
    @espiegel123

    @espiegel123 said:
    @pejman : are you asking when people use underscore or how do they decide that a variable is safe to use as if it were a local variable?

    Hi.
    Exactly both are my questions.

    The underscore is ki’s personal convention.

    I don’t use the same one. I keep track by using comments. I generally initialize all “non-local” variables in onLoad and include a comment about the variable’s use unless a program is trivially short and only for me.

    In my opinion, re-using variables (which is what we are really talking about since all variables are global) is something that you should only do if you can reliably follow (trace through) your code and be certain that no routine that uses a pseudo-local variable calls another routine that would also be using it as a local variable while the original routine was still using it.

    You need to have a solid ability to understand your code to do this and the ability to track down accidental mis-uses.

  • wimwim
    edited December 2023

    The bottom line @pejman is the underscore has no function other than as a visual aid for code readability. It has no effect on the variable's scope or what it does. You could do something similar using all caps for variable names, or comments. Whatever helps you navigate and understand your code better.

    I tend to use the underscore before variables that aren't mean to change values. Mozaic doesn't have constants, but constants are useful. So, I put the underscore before variables that I'm treating as constants. That way it's obvious that I should never be changing their values.

    @_ki 's wonderful Textastic grammar formats variables starting with underscore differently so that they stand out even more obviously as variables meant to be treated differently.

  • _ki_ki
    edited December 2023

    @espiegel123 As @wim already wrote: The idea for that convention came with my Textastic Mozaic highlighter.

    Since it is very helpful during development to be reminded of the intended purpose of a variable i implemented different styling rules depending on the name used:

    The syntax-highlighting and full syntax-validator for Mozaic had to be written in a strange sublime syntax defintion language, where tons of tons of regular expressions and rules form a kind of EBNF for the language.
    So the new ‚imaginary types‘ local and param had to follow special rules. The distinction based on the first letter and the definition of the rules for the following letters was an obvious decision that easily translated into a regex :)

    That screenshot is from the extensive unittest file for the language definition, showcasing that only names exactly following the specific rule are shown with a different style and that normal style is used otherwise.

  • Thanks @_ki - I had somehow overlooked the other variables styling rules. I will adopt some of these in future scripts. 👍🏼

  • heshes
    edited December 2023

    @wim said:
    The bottom line @pejman is the underscore has no function other than as a visual aid for code readability. It has no effect on the variable's scope or what it does.

    True. But if it's used to designate local variables, then I think the underscore should be a flag that is slightly more than an aid for readability. It should serve as a flag that in any function the first use of a variable preceded by an underscore (i.e., a variable to be treated as local) should always be assigning it a value. This is so you can use the same variable in many different functions, but treat it as a local variable in all of them, never needing to worry about whether its value has been changed in some other function.

    @OnMIDIInput
    
       _somelocalvar = 10     // assign it a value before you use it
      // followed by code that does something with _somelocalvar
    
    @End
    
    @OnMIDINoteOn
    
       _somelocalvar = 20     // assign it a value before you use it
      // followed by code that does something with _somelocalvar
    
    @END
    

    If you follow this convention by using, e.g., _i, as a local variable you can skip explicit assignment if you're using it as a variable to hold values of a for loop or while loop (which implicitly assign values to _i). (In practice you might abandon underscore convention for a variable named 'i' if you always just use it as counter in loops, but principle is the same: if a variable is intended to be local always assign it a value before you use it.) :

    @SomeFunction
    
      for _i = 0 to 10 
         // code here using _i
      endfor
    
    @END 
    
    @SomeOtherFunction
    
      for _i = 0 to 20
          // code here using _i
      endfor
    
    @END 
    
  • And make sure you don’t call a routine with a for loop that uses _i from inside a for loop that is using _i

  • wimwim
    edited December 2023

    @hes said:

    @wim said:
    The bottom line @pejman is the underscore has no function other than as a visual aid for code readability. It has no effect on the variable's scope or what it does.

    True. But if it's used to designate local variables, then I think the underscore should be a flag that is slightly more than an aid for readability. It should serve as a flag that in any function the first use of a variable preceded by an underscore (i.e., a variable to be treated as local) should always be assigning it a value. This is so you can use the same variable in many different functions, but treat it as a local variable in all of them, never needing to worry about whether its value has been changed in some other function.

    The point I wanted to be sure @pejman understood was: there is no change of variable function provided by the underscore (or any other naming convention). Perhaps I used too many words. I'm repeating it here in case the rest of these posts obscure that main point.

Sign In or Register to comment.