This new grouping model takes a bit of getting used to, IMO.

To be honest, I kinda miss the old way of grouping events ...
particularly the ability to quickly, and separately, lengthen or
shorten individual event splice points on either side of a multitrack
join. IOW, making diagonal splices - or varying, from track to track,
the points where you join grouped events to get a seamless multitrack
edit - does not seem as easy to do as before, unless I am just
missing something obvious ... but for now I'll take the added
features over ease of that operation.

Lest we sound ungrateful, and for a stark lesson in reality, just
crank up a copy of CuBase and try doing some "audio only" after using
Vegas for a while. AAMOF, I can now barely tolerate WaveLab after
just a short time using the Vegas interface. It would be a pleasure
to see a 24/96, 2 track editor out of SF sometime this century with a
Vegas style interface. Vegas may not be everyone's dream, but it
inarguably has the best interface of any audio software I've used to
date.

KAC ...

Charles de Montebello wrote:
>>Group the events (in v. 2.0) and then trim the ends and all events
>>should trim simultaneously.
>>
>>mcm wrote:
>>>>Is there a way to select more than one track and then
>>>>lengthen or shorten all of them together by grabbing the
>>>>end of the one track or tracks? Thank you, mcm

I agree with you, Karl. I think the new grouping is a little
confusing at first. I was mostly confused by the fact that when you
now click on an event in a group, it no longer selects all events in
that group. It makes identifying that you have actually selected an
event in a group difficult. I suggested to them that they highlight
the event with the same dark blue line that surrounds it when you
drag... Maybe that'll make it in there in some way or another. Alos,
in order to drag a group to a different track you have to select all
events in the group. It's all a little more time consuming. The edge
trimming feature is nice, though, and for Karl I would recommend
the "Ignore Event Grouping" for moments like those you were talking
about. It's handy to work with elements of a group and then regroup
them with the click of a button.


Karl Caillouet wrote:
>>This new grouping model takes a bit of getting used to, IMO.
>>
>>To be honest, I kinda miss the old way of grouping events ...
>>particularly the ability to quickly, and separately, lengthen or
>>shorten individual event splice points on either side of a
multitrack
>>join. IOW, making diagonal splices - or varying, from track to
track,
>>the points where you join grouped events to get a seamless
multitrack
>>edit - does not seem as easy to do as before, unless I am just
>>missing something obvious ... but for now I'll take the added
>>features over ease of that operation.
>>
>>Lest we sound ungrateful, and for a stark lesson in reality, just
>>crank up a copy of CuBase and try doing some "audio only" after
using
>>Vegas for a while. AAMOF, I can now barely tolerate WaveLab after
>>just a short time using the Vegas interface. It would be a pleasure
>>to see a 24/96, 2 track editor out of SF sometime this century with
a
>>Vegas style interface. Vegas may not be everyone's dream, but it
>>inarguably has the best interface of any audio software I've used
to
>>date.
>>
>>KAC ...
>>
>>Charles de Montebello wrote:
>>>>Group the events (in v. 2.0) and then trim the ends and all
events
>>>>should trim simultaneously.
>>>>
>>>>mcm wrote:
>>>>>>Is there a way to select more than one track and then
>>>>>>lengthen or shorten all of them together by grabbing the
>>>>>>end of the one track or tracks? Thank you, mcm

The more I think about it, and the more I confront the new grouping
model, the more I am convinced that the idea of "grouping" audio
tracks has been somewhat subverted in VV.

I primarily "grouped" events in the past so that I could perform two
functions: 1 - treat the separate events in each group as a whole
when performing edits, trimming, moving, etc, and 2 - maintain the
time relationship between the various events of the group(s) when
doing the same.

Both those, while still possible, don't appear to be default and seem
to now take keystrokes or extra mouse clicks to accomplish ... and I
have to admit that I am not exactly sure at this point what it is
that I, as an audio person, have gained in the tradeoff?

Granted, we rarely use Vegas for recording, but more as a multitrack
editor and as an aide for mixing to analog though a console, so I am
certainly looking at the beast from the belly up and may well be
missing some vital uses of the new grouping model, particularly as
pertains to audio for video.

If the latter is the case, then it represents to me just one more
instance of audio being treated as secondary, and as the red haired
step child, when it come to video.

Just my .02.

KAC ...


Charles de Montebello wrote:
>>I agree with you, Karl. I think the new grouping is a little
>>confusing at first. I was mostly confused by the fact that when you
>>now click on an event in a group, it no longer selects all events
in
>>that group. It makes identifying that you have actually selected an
>>event in a group difficult. I suggested to them that they highlight
>>the event with the same dark blue line that surrounds it when you
>>drag... Maybe that'll make it in there in some way or another.

I have to agree that we've subverted grouping, but I can't understand
your objection to it Karl. IMHO 2.0 grouping does time sync MUCH
better than 1.0.

In 1.0. groups were basically 'frozen selections'. Grouping events
guranteed that you would be unable to select only one member of a
group, which in turn caused ALL edits that recognized selections to
operate on all group members. (but not all edits recognize
selections...)

1.0 groups did not in fact work very well to keep things in time
because edge dragging and slipping of event data doesn't (and can't)
pay attention to selections.

Since 1.0 groups were frozen selections, there were a whole boatload
of bad behaviors that fell out. (For instance, it became impossible to
delete, or copy a single event without first ungrouping it). Of all
of the edit operations for groups, only about 30% actually made sense
to do on all group members all of the time. With the advent of 2
types of tracks, it became impossible to move grouped events from
track to track in many cases. (because you can't move video events to
audio tracks and v.v.)

In 2.0 we got rid of that form of grouping, and created a new form
I like to call 'Time locking'. I'd prefer we not use the term 'group'
at all because it just confuses the issue.

Our timelock groups affect ALL operations that affect the placement
of audio & video in time in such a way as to try and keep what was in
sync before locking, in sync after.

This has nothing to do with treating audio as secondary. In fact,
time locking makes very little sense in a video-only environment.

What we did (or tried to do) was to replace a partially useful
'frozen selection' model of grouping. With a truely useful 'keep in
sync' model of grouping.

Ok, so clearly you think we failed. I'd like to ask:
In what way? Did you just prefer 'frozen selctions' with
all of their warts? Or is the problem that we confused
you by calling both 1.0 & 2.0 features 'groups' when in fact
they are completely different?

tj


Karl Caillouet wrote:
>>The more I think about it, and the more I confront the new grouping
>>model, the more I am convinced that the idea of "grouping" audio
>>tracks has been somewhat subverted in VV.
>>
>>I primarily "grouped" events in the past so that I could perform
two
>>functions: 1 - treat the separate events in each group as a whole
>>when performing edits, trimming, moving, etc, and 2 - maintain the
>>time relationship between the various events of the group(s) when
>>doing the same.
>>
>>Both those, while still possible, don't appear to be default and
seem
>>to now take keystrokes or extra mouse clicks to accomplish ... and
I
>>have to admit that I am not exactly sure at this point what it is
>>that I, as an audio person, have gained in the tradeoff?
>>
>>Granted, we rarely use Vegas for recording, but more as a
multitrack
>>editor and as an aide for mixing to analog though a console, so I
am
>>certainly looking at the beast from the belly up and may well be
>>missing some vital uses of the new grouping model, particularly as
>>pertains to audio for video.
>>
>>If the latter is the case, then it represents to me just one more
>>instance of audio being treated as secondary, and as the red haired
>>step child, when it come to video.
>>
>>Just my .02.
>>
>>KAC ...
>>
>>
>>Charles de Montebello wrote:
>>>>I agree with you, Karl. I think the new grouping is a little
>>>>confusing at first. I was mostly confused by the fact that when
you
>>>>now click on an event in a group, it no longer selects all events
>>in
>>>>that group. It makes identifying that you have actually selected
an
>>>>event in a group difficult. I suggested to them that they
highlight
>>>>the event with the same dark blue line that surrounds it when you
>>>>drag... Maybe that'll make it in there in some way or another.

I realize that this is but a small part of a feature rich program,
but my point is that it now takes longer, and necessitates more
keystrokes and mouse clicks, to perform the same functions for which
ver. 1 "groups" were useful for audio users.

>>1.0 groups did not in fact work very well to keep things in time
>>because edge dragging and slipping of event data doesn't (and can't)
>>pay attention to selections.

Perhaps because I have not really had a chance to put the slip
feature through its paces, the ability to "slip" within a grouped
event has yet to have a bearing on my gripes about the changes in
what we are now calling "groups". I have to admit that, for the way
I've used Vegas thus far, I've yet to see a need for slipping in this
manner ... that, of course, in no way denigrates the feature and
doesn't mean I won't start using it in earnest in the future.

>>Since 1.0 groups were frozen selections, there were a whole boatload
>>of bad behaviors that fell out. (For instance, it became impossible
to >>delete, or copy a single event without first ungrouping it).

That was done with a single mouse click ... now, in order to
really "group" events for ANY operation it takes an extra mouse click
and a keystroke just to get started AFTER having supposedly
already "grouped" the events you want to work with in that manner.

In practice, I rarely found it necessary to "ungroup" events for
the most part once they were "grouped" ... and when I did it was a
simple right mouse click to do so.

Of all
>>of the edit operations for groups, only about 30% actually made
sense
>>to do on all group members all of the time. With the advent of 2
>>types of tracks, it became impossible to move grouped events from
>>track to track in many cases. (because you can't move video events
to audio tracks and v.v.)

Ah so! .... as I suspected all along ... this ver. 2 method
of "grouping" of audio tracks does indeed find itself based on what
works with, and is possible with, video and not necessarily on what
was convenient for us audio only users! :)

>>
>>In 2.0 we got rid of that form of grouping, and created a new form
>>I like to call 'Time locking'. I'd prefer we not use the
term 'group' at all because it just confuses the issue.
>>
>>Our timelock groups affect ALL operations that affect the placement
>>of audio & video in time in such a way as to try and keep what was
in >>sync before locking, in sync after.

But, as far as audio is concerned, not without keystrokes and mouse
clicks to actually "group" again the events that were supposedly
already "grouped" before attempting "placement".

>>
>>This has nothing to do with treating audio as secondary. In fact,
>>time locking makes very little sense in a video-only environment.

Sorry, I don't necessarily buy that ... you had a very convenient
feature for handling multiple audio tracks that has apparently been
made less convenient and more complicated because of the video side.

>>What we did (or tried to do) was to replace a partially useful
>>'frozen selection' model of grouping. With a truely useful 'keep in
>>sync' model of grouping.

Keep in sync with what, the video? You lost me there ... when
I "grouped" events in ver 1, they stayed "in sync" with each other
until I "ungrouped" and moved them individually ... that is not
necessarily the case now, at least not without some extra steps.

It would be nice to get a more in-depth explanation from you as to
why your new 'keep in sync' benefits us strictly audio users ... It
is entirely possible that I am missing the big picture from my
admitted newness to the program.

>>
>>Ok, so clearly you think we failed. I'd like to ask:
>>In what way? Did you just prefer 'frozen selctions' with
>>all of their warts? Or is the problem that we confused
>>you by calling both 1.0 & 2.0 features 'groups' when in fact
>>they are completely different?

John, if we used Vegas for anything at all, we used it HEAVILY for
editing mulit-track projects ... and in the process we became very
proficient and expert at using the program and its features for that
purpose. I can't help but notice that, for our purposes,
the "grouping" feature in ver. 1 was much faster, more convenient,
and easier to use for editing multitrack audio projects than it is in
ver. 2.

We certainly have no intention of abandoning the product because of
this. AAMOF, we have already paid our money and still find it a
fantastic product. And, I am sure that, as we learn more about the
new features, we will find more and more uses for them ... although
that strikes me as a uniquely bass ackwards approach. :)

I still have a gut feeling - and as I suspected the very minute I
heard the word "video" being associated with Vegas Pro - that.
because of the video, you guys have NOT given us the audio
improvements that I would have expected to see in a version 2 of
an "audio only" Vegas Pro. Sorry, but the more I hear from you guys
on the justification for some of these seemingly small changes, the
more I suspect that is the case.

Nonetheless, you've still done a damn good job with the program! ...
so just let some of us "audio only" guys kick a bit and try to
understand. Thanks. :)

KAC ...

I totally agree with Karl.
It seems to me that the current focus is on a "universal" application
that attracts the widest user-base. There's nothing wrong with that.
What creates some friction (and Karl has been VERY polite in
expressing his feelings) is the fact that Sonic Foundry has a way of
not being clear in its intentions.
I think that the majority of users are audio people like me, who don't
want to abandon a product that we have invested so much time and money
on. We put up with the "growing pains" of what was, essentially, a
beta release in version 1.0, and were hoping version 2.0 would show
significant improvements, but that's not necessarily the case here.It
is only natural that we expect Sonic Foundry to reciprocate our good
faith, especially on the face of some many NEW competing products...

Victor Harriman



Karl Caillouet wrote:
>>I realize that this is but a small part of a feature rich program,
>>but my point is that it now takes longer, and necessitates more
>>keystrokes and mouse clicks, to perform the same functions for which
>>ver. 1 "groups" were useful for audio users.
>>
>>>>1.0 groups did not in fact work very well to keep things in time
>>>>because edge dragging and slipping of event data doesn't (and
can't)
>>>>pay attention to selections.
>>
>>Perhaps because I have not really had a chance to put the slip
>>feature through its paces, the ability to "slip" within a grouped
>>event has yet to have a bearing on my gripes about the changes in
>>what we are now calling "groups". I have to admit that, for the way
>>I've used Vegas thus far, I've yet to see a need for slipping in
this
>>manner ... that, of course, in no way denigrates the feature and
>>doesn't mean I won't start using it in earnest in the future.
>>
>>>>Since 1.0 groups were frozen selections, there were a whole
boatload
>>>>of bad behaviors that fell out. (For instance, it became
impossible
>>to >>delete, or copy a single event without first ungrouping it).
>>
>>That was done with a single mouse click ... now, in order to
>>really "group" events for ANY operation it takes an extra mouse
click
>>and a keystroke just to get started AFTER having supposedly
>>already "grouped" the events you want to work with in that manner.
>>
>>In practice, I rarely found it necessary to "ungroup" events for
>>the most part once they were "grouped" ... and when I did it was a
>>simple right mouse click to do so.
>>
>> Of all
>>>>of the edit operations for groups, only about 30% actually made
>>sense
>>>>to do on all group members all of the time. With the advent of 2
>>>>types of tracks, it became impossible to move grouped events from
>>>>track to track in many cases. (because you can't move video events
>>to audio tracks and v.v.)
>>
>>Ah so! .... as I suspected all along ... this ver. 2 method
>>of "grouping" of audio tracks does indeed find itself based on what
>>works with, and is possible with, video and not necessarily on what
>>was convenient for us audio only users! :)
>>
>>>>
>>>>In 2.0 we got rid of that form of grouping, and created a new form
>>>>I like to call 'Time locking'. I'd prefer we not use the
>>term 'group' at all because it just confuses the issue.
>>>>
>>>>Our timelock groups affect ALL operations that affect the
placement
>>>>of audio & video in time in such a way as to try and keep what was
>>in >>sync before locking, in sync after.
>>
>>But, as far as audio is concerned, not without keystrokes and mouse
>>clicks to actually "group" again the events that were supposedly
>>already "grouped" before attempting "placement".
>>
>>>>
>>>>This has nothing to do with treating audio as secondary. In fact,
>>>>time locking makes very little sense in a video-only environment.
>>
>>Sorry, I don't necessarily buy that ... you had a very convenient
>>feature for handling multiple audio tracks that has apparently been
>>made less convenient and more complicated because of the video side.
>>
>>>>What we did (or tried to do) was to replace a partially useful
>>>>'frozen selection' model of grouping. With a truely useful 'keep
in
>>>>sync' model of grouping.
>>
>>Keep in sync with what, the video? You lost me there ... when
>>I "grouped" events in ver 1, they stayed "in sync" with each other
>>until I "ungrouped" and moved them individually ... that is not
>>necessarily the case now, at least not without some extra steps.
>>
>>It would be nice to get a more in-depth explanation from you as to
>>why your new 'keep in sync' benefits us strictly audio users ... It
>>is entirely possible that I am missing the big picture from my
>>admitted newness to the program.
>>
>>>>
>>>>Ok, so clearly you think we failed. I'd like to ask:
>>>>In what way? Did you just prefer 'frozen selctions' with
>>>>all of their warts? Or is the problem that we confused
>>>>you by calling both 1.0 & 2.0 features 'groups' when in fact
>>>>they are completely different?
>>
>>John, if we used Vegas for anything at all, we used it HEAVILY for
>>editing mulit-track projects ... and in the process we became very
>>proficient and expert at using the program and its features for that
>>purpose. I can't help but notice that, for our purposes,
>>the "grouping" feature in ver. 1 was much faster, more convenient,
>>and easier to use for editing multitrack audio projects than it is
in
>>ver. 2.
>>
>>We certainly have no intention of abandoning the product because of
>>this. AAMOF, we have already paid our money and still find it a
>>fantastic product. And, I am sure that, as we learn more about the
>>new features, we will find more and more uses for them ... although
>>that strikes me as a uniquely bass ackwards approach. :)
>>
>>I still have a gut feeling - and as I suspected the very minute I
>>heard the word "video" being associated with Vegas Pro - that.
>>because of the video, you guys have NOT given us the audio
>>improvements that I would have expected to see in a version 2 of
>>an "audio only" Vegas Pro. Sorry, but the more I hear from you guys
>>on the justification for some of these seemingly small changes, the
>>more I suspect that is the case.
>>
>>Nonetheless, you've still done a damn good job with the program! ...
>>so just let some of us "audio only" guys kick a bit and try to
>>understand. Thanks. :)
>>
>>KAC ...

Ok. I think I see what you are saying. Basically, you liked
groups-as-frozen-selections. It was useful to you.

You said:
Ah so! .... as I suspected all along ... this ver. 2 method
of "grouping" of audio tracks does indeed find itself based on what
works with, and is possible with, video and not necessarily on what
was convenient for us audio only users! :)

This is partly true. But mostly not true. The original intent of
groups was to solve the 'keeping audio in sync once you got it right'
problem. And groups-as-frozen-selections didn't do that very well.

If I had won the argument in Vegas 1.0. we would have had groups-as-
time-lock from the very beginning. That's what we added groups for,
but we just cheezed out and didn't do it correctly. We ended up with
groups-as-frozen-selections because it was easy to do, not because it
was correct.

I won that argument (finally) in 2.0 in part because groups-as-frozen-
selections became clearly broken when we tried to make use of them in
a mixed media environment. (Note that mixed media would be
midi/audio as well, so even an audio-only multitrack would still have
to confront this someday)

I still think that groups-as-time-lock is a necessary feature, and
should be the default grouping behavior. But what I'm hearing from
you is that groups-as-frozen-selections is ALSO a necessary feature,
and you don't like having it be an extra step.

Ok, so when we fix this. Would you prefer to basically give you a
preference: Groups are compatible with Vegas Audio 1.0.

Or do we need to have 2 types of groups, and let you set group
behavior by setting the type of a group?

tj

Karl Caillouet wrote:
>>I realize that this is but a small part of a feature rich program,
>>but my point is that it now takes longer, and necessitates more
>>keystrokes and mouse clicks, to perform the same functions for
which
>>ver. 1 "groups" were useful for audio users.
>>
>>>>1.0 groups did not in fact work very well to keep things in time
>>>>because edge dragging and slipping of event data doesn't (and
can't)
>>>>pay attention to selections.
>>
>>Perhaps because I have not really had a chance to put the slip
>>feature through its paces, the ability to "slip" within a grouped
>>event has yet to have a bearing on my gripes about the changes in
>>what we are now calling "groups". I have to admit that, for the way
>>I've used Vegas thus far, I've yet to see a need for slipping in
this
>>manner ... that, of course, in no way denigrates the feature and
>>doesn't mean I won't start using it in earnest in the future.
>>
>>>>Since 1.0 groups were frozen selections, there were a whole
boatload
>>>>of bad behaviors that fell out. (For instance, it became
impossible
>>to >>delete, or copy a single event without first ungrouping it).
>>
>>That was done with a single mouse click ... now, in order to
>>really "group" events for ANY operation it takes an extra mouse
click
>>and a keystroke just to get started AFTER having supposedly
>>already "grouped" the events you want to work with in that manner.
>>
>>In practice, I rarely found it necessary to "ungroup" events for
>>the most part once they were "grouped" ... and when I did it was a
>>simple right mouse click to do so.
>>
>> Of all
>>>>of the edit operations for groups, only about 30% actually made
>>sense
>>>>to do on all group members all of the time. With the advent of 2
>>>>types of tracks, it became impossible to move grouped events from
>>>>track to track in many cases. (because you can't move video
events
>>to audio tracks and v.v.)
>>
>>Ah so! .... as I suspected all along ... this ver. 2 method
>>of "grouping" of audio tracks does indeed find itself based on what
>>works with, and is possible with, video and not necessarily on what
>>was convenient for us audio only users! :)
>>
>>>>
>>>>In 2.0 we got rid of that form of grouping, and created a new form
>>>>I like to call 'Time locking'. I'd prefer we not use the
>>term 'group' at all because it just confuses the issue.
>>>>
>>>>Our timelock groups affect ALL operations that affect the
placement
>>>>of audio & video in time in such a way as to try and keep what
was
>>in >>sync before locking, in sync after.
>>
>>But, as far as audio is concerned, not without keystrokes and mouse
>>clicks to actually "group" again the events that were supposedly
>>already "grouped" before attempting "placement".
>>
>>>>
>>>>This has nothing to do with treating audio as secondary. In
fact,
>>>>time locking makes very little sense in a video-only environment.
>>
>>Sorry, I don't necessarily buy that ... you had a very convenient
>>feature for handling multiple audio tracks that has apparently been
>>made less convenient and more complicated because of the video side.
>>
>>>>What we did (or tried to do) was to replace a partially useful
>>>>'frozen selection' model of grouping. With a truely useful 'keep
in
>>>>sync' model of grouping.
>>
>>Keep in sync with what, the video? You lost me there ... when
>>I "grouped" events in ver 1, they stayed "in sync" with each other
>>until I "ungrouped" and moved them individually ... that is not
>>necessarily the case now, at least not without some extra steps.
>>
>>It would be nice to get a more in-depth explanation from you as to
>>why your new 'keep in sync' benefits us strictly audio users ... It
>>is entirely possible that I am missing the big picture from my
>>admitted newness to the program.
>>
>>>>
>>>>Ok, so clearly you think we failed. I'd like to ask:
>>>>In what way? Did you just prefer 'frozen selctions' with
>>>>all of their warts? Or is the problem that we confused
>>>>you by calling both 1.0 & 2.0 features 'groups' when in fact
>>>>they are completely different?
>>
>>John, if we used Vegas for anything at all, we used it HEAVILY for
>>editing mulit-track projects ... and in the process we became very
>>proficient and expert at using the program and its features for
that
>>purpose. I can't help but notice that, for our purposes,
>>the "grouping" feature in ver. 1 was much faster, more convenient,
>>and easier to use for editing multitrack audio projects than it is
in
>>ver. 2.
>>
>>We certainly have no intention of abandoning the product because of
>>this. AAMOF, we have already paid our money and still find it a
>>fantastic product. And, I am sure that, as we learn more about the
>>new features, we will find more and more uses for them ... although
>>that strikes me as a uniquely bass ackwards approach. :)
>>
>>I still have a gut feeling - and as I suspected the very minute I
>>heard the word "video" being associated with Vegas Pro - that.
>>because of the video, you guys have NOT given us the audio
>>improvements that I would have expected to see in a version 2 of
>>an "audio only" Vegas Pro. Sorry, but the more I hear from you guys
>>on the justification for some of these seemingly small changes, the
>>more I suspect that is the case.
>>
>>Nonetheless, you've still done a damn good job with the
program! ...
>>so just let some of us "audio only" guys kick a bit and try to
>>understand. Thanks. :)
>>
>>KAC ...

John,

IMO, your questions below deserve more than a cursory answer.

I was, in fact, going to test your grouping philosophy in earnest
during a session with a large horn group today in order to give you
some more thoughts on the subject, but, as luck would have it, VV
froze up, quit recording, periodically locked input meters on random
tracks, BSOD'ed and generally misbehaved.

I tried going back to VP which is still installed (that may well be
the reason for VV to act up? ... Peter, anyone?)... but by that time,
the producer had decided to try another approach. During some down
time in the studio this Sunday I will try to get a stable
installation of VV and will then hopefully be able to give you a
reasonably informed response later in the week.

BTW, SF's participation in this discussion speaks highly of your
organization. Besides being extremely rare in this business, there is
NO better indication of the quality and care that goes into your
products ... nuff said.

KAC ...


John M. Knoeller wrote:

>>Ok, so when we fix this. Would you prefer to basically give you a
>>preference: Groups are compatible with Vegas Audio 1.0.
>>
>>Or do we need to have 2 types of groups, and let you set group
>>behavior by setting the type of a group?