Enhancement, AFP Move selection in AFP with mouse on GUI

[musikBear]

I have just played a little with AFP, and it struck me, that it would be a neat thing, if it was possible to move start-point and end-point, at the same time, with only one diel. That could make it possible to get easy exactness with selections in several AFPs (copied) ao used as 'phrase-finder' in a larger sample.
I think alt+diel-movement, could push/ drag the other diels values, in equel amount, and 'alt' is not in use.

[Sti2nd]

The feature was removed because of some reason

[tobydox]

You can achieve this using a controller which is connected to both knobs. Not a perfect and super convenient solution but it works ;-) Alternatively we could think about implementing support for linking controls with a specific offset/difference.

[musikBear]

toby, that of cause a good fix, for moving several diels simultanous, but at the same value. In this circumstance its exactly the 'specific-offset' that is needed, but Thanks for the heads up! 👍
-o-
Did some more fiddeling. A way to get preettii close to getting different selections of same size, is to set a fixed span with the diels, but then move the sample around. The span in ms remain the same, but the posistion in the sample changes. The only problem here, is that not the whole samle can be placed inside the span. (audacity can be used to to fix that, ofcause)

[diizy]

I think a led switch labeled "lock offset" could be added, which would make the offset between the different points (start, loopback, end) static, so that moving one affects all three. Only question is, how to handle boundaries?

I'll mark this for 1.2.

[tresf]

I would recommend the functionality is brought (back?) to the GUI and the CTRL+DRAG is honored. I find no reason to add more items to the GUI when what we have is completely logical.

In terms of boundaries, it would either add silence to the bounding end and keep pattern length or it would never allow values out of range, or at least that's how I would envision it.

Was it actually removed? If so, what was the reasoning?

-Tres

[diizy]

On 06/12/2014 06:32 AM, Tres Finocchiaro wrote:

I would recommend the functionality is brought (back?) to the GUI and
the CTRL+DRAG is honored. I find no reason to add more items to the
GUI when what we have is completely logical.

In terms of boundaries, it would either add silence to the bounding
end and keep pattern length or it would never allow values out of
range, or at least that's how I would envision it.

Was it actually removed? If so, what was the reasoning?

Nothing was removed.

In terms of boundaries, adding silence is problematic since we don't
actually modify the sample data in any way, we just read it from a file
and maybe perform one of a couple of simple operations (reverse,
amplify). Even if we had infrastructure in place for modifying sample
files (we kind of do, halfway, but not properly implemented yet), it
wouldn't be a good idea to modify the samples in such a non-transparent,
easy-to-do-by-accident way.

I think we have 3 options when it comes to boundaries:

1. selection is like a brick: stop the move of all loop points when
   boundary is hit
2. if you're moving the opposite/middle end: squash the selection when
   it hits the boundary
3. same as above, but bounce back when moving backwards (this would be
   the hardest to implement)

[eagles051387]

I think the easiest way would be the way Logic Pro does it. They have
something called a bus (
http://www.askaudiomag.com/articles/how-to-best-use-bus-channels-in-logic-pro)
the way this article puts it is that a bus is used to send a signal from
one channel on the bus to the other. I am not sure if this is what would be
useful in this case or not. What is interesting in terms of these buses is
that logic somehow manages to have 64 of them.

What I am worried about with what I mentioned above is the complexity of it
all.

On Thu, Jun 12, 2014 at 8:11 AM, Vesa V [email protected] wrote:

On 06/12/2014 06:32 AM, Tres Finocchiaro wrote:

I would recommend the functionality is brought (back?) to the GUI and
the CTRL+DRAG is honored. I find no reason to add more items to the
GUI when what we have is completely logical.

In terms of boundaries, it would either add silence to the bounding
end and keep pattern length or it would never allow values out of
range, or at least that's how I would envision it.

Was it actually removed? If so, what was the reasoning?

Nothing was removed.

In terms of boundaries, adding silence is problematic since we don't
actually modify the sample data in any way, we just read it from a file
and maybe perform one of a couple of simple operations (reverse,
amplify). Even if we had infrastructure in place for modifying sample
files (we kind of do, halfway, but not properly implemented yet), it
wouldn't be a good idea to modify the samples in such a non-transparent,
easy-to-do-by-accident way.

I think we have 3 options when it comes to boundaries:

1. selection is like a brick: stop the move of all loop points when
   boundary is hit
2. if you're moving the opposite/middle end: squash the selection when
   it hits the boundary
3. same as above, but bounce back when moving backwards (this would be
   the hardest to implement)

—
Reply to this email directly or view it on GitHub
#794 (comment).

Jonathan Aquilina

[diizy]

On 06/12/2014 09:26 AM, eagles051387 wrote:

I think the easiest way would be the way Logic Pro does it. They have
something called a bus (
http://www.askaudiomag.com/articles/how-to-best-use-bus-channels-in-logic-pro)

the way this article puts it is that a bus is used to send a signal from
one channel on the bus to the other. I am not sure if this is what
would be
useful in this case or not. What is interesting in terms of these
buses is
that logic somehow manages to have 64 of them.

What I am worried about with what I mentioned above is the complexity
of it
all.

What I'm worried about is how do buses have anything to do with fixing
the distance between knobs???

[eagles051387]

I misunderstood i thought this had to do with starting and end points of
multiple tracks in a project.

On Thu, Jun 12, 2014 at 8:35 AM, Vesa V [email protected] wrote:

On 06/12/2014 09:26 AM, eagles051387 wrote:

I think the easiest way would be the way Logic Pro does it. They have
something called a bus (

http://www.askaudiomag.com/articles/how-to-best-use-bus-channels-in-logic-pro
)

the way this article puts it is that a bus is used to send a signal from
one channel on the bus to the other. I am not sure if this is what
would be
useful in this case or not. What is interesting in terms of these
buses is
that logic somehow manages to have 64 of them.

What I am worried about with what I mentioned above is the complexity
of it
all.

What I'm worried about is how do buses have anything to do with fixing
the distance between knobs???

—
Reply to this email directly or view it on GitHub
#794 (comment).

Jonathan Aquilina

[musikBear]

1. selection is like a brick: stop the move of all loop points when boundary is hit

I think this is intuitive. It will give user a chance to move the selection and the selection will be uniform at all time. This could be of importance, if the user maticulary has achived a perfect length, then a 'squese' would look a lot like sabotage :p
Qe : should there be a 'special' diel (space on GUI??) for simultanous moving, or just a check-box? (taggy??)
..in fact a dedicated diel would be simpler to implement -right?

[tresf]

Qe : should there be a 'special' diel (space on GUI??) for simultanous moving, or just a check-box? (taggy??)
..in fact a dedicated diel would be simpler to implement -right?

Neither, IMO. It should be left and right draggable (which is currently not bound to anything) and CTRL + Drag to a Automation track should allow automation performed on it's position. This is fairly standard for wave selection interfaces I've used.

selection is like a brick: stop the move of all loop points when boundary is hit

👍

[Sti2nd]

Could you update the title @musikBear "Move selection in AFP with mouse on GUI/waveform" or something.

[musikBear]

@Sti2nd done :)

[Umcaruje]

Well, I'm not sure when this was implemented, but this issue is fixed in the master branch:

So I'm closing it.