Hi there! I have completed the first parts of an opcode I've been
working on. What it does is take a table, add some "jitter" to a
certain amount of the elemets of the table, and save the new
information to a new table. It is sort of like a cross between jitter
and a mass-spring system, though it's not entirely like either.

The project started out as a UDO in which I used the jitter opcode X
amount of times in order to wobble all the elements of a table. It
lagged when I started using big table sizes, so I decided I should
write an opcode to do it in the most efficient way I could think of.

I've got some more things to test and add, but there are currently 4
working version of it, so I thought I would share it and see what you
guys think.

ps. I think that all the code should compile as plain C aswell as C++,
but I haven't tried it yet.

Pete

-- 
http://algorythmradio.com
https://soundcloud.com/algorythmradio

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Certainly will! I'll post it tomorrow

On Fri, Apr 15, 2016 at 6:27 PM, Rory Walsh  wrote:
> Hi Peter, Would you mind posting the a .csd with the UDO so those who can't
> compile it themselves might be able hear what it sounds like?
>
> On 15 April 2016 at 17:54, Peter Burgess 
> wrote:
>>
>> Hi there! I have completed the first parts of an opcode I've been
>> working on. What it does is take a table, add some "jitter" to a
>> certain amount of the elemets of the table, and save the new
>> information to a new table. It is sort of like a cross between jitter
>> and a mass-spring system, though it's not entirely like either.
>>
>> The project started out as a UDO in which I used the jitter opcode X
>> amount of times in order to wobble all the elements of a table. It
>> lagged when I started using big table sizes, so I decided I should
>> write an opcode to do it in the most efficient way I could think of.
>>
>> I've got some more things to test and add, but there are currently 4
>> working version of it, so I thought I would share it and see what you
>> guys think.
>>
>> ps. I think that all the code should compile as plain C aswell as C++,
>> but I haven't tried it yet.
>>
>> Pete
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Ok, here are the original csd's I was experimenting with. Sorry, I
didn't mean to say UDO, they are just in insturments. When I tried to
make the UDO's I hit major problems.

In each example, the first two instruments control themselves, and the
next 3 instruments are controlled by you.

metallizer.csd has 2 controls, metallizerDetuned.csd has 3 (an extra
one for detuning). The controls are 1 -> 3 on the virtual midi
keyboard. I don't think I ever setup detune on the first 2 or 3
instruments in metallizerDetuned.csd, So try out the later 2 or 3
instruments from that one.

Enjoy!

On Fri, Apr 15, 2016 at 11:04 PM, Rory Walsh  wrote:
> Cheers.
>
> On 15 April 2016 at 20:51, Peter Burgess 
> wrote:
>>
>> Certainly will! I'll post it tomorrow
>>
>> On Fri, Apr 15, 2016 at 6:27 PM, Rory Walsh  wrote:
>> > Hi Peter, Would you mind posting the a .csd with the UDO so those who
>> > can't
>> > compile it themselves might be able hear what it sounds like?
>> >
>> > On 15 April 2016 at 17:54, Peter Burgess
>> > 
>> > wrote:
>> >>
>> >> Hi there! I have completed the first parts of an opcode I've been
>> >> working on. What it does is take a table, add some "jitter" to a
>> >> certain amount of the elemets of the table, and save the new
>> >> information to a new table. It is sort of like a cross between jitter
>> >> and a mass-spring system, though it's not entirely like either.
>> >>
>> >> The project started out as a UDO in which I used the jitter opcode X
>> >> amount of times in order to wobble all the elements of a table. It
>> >> lagged when I started using big table sizes, so I decided I should
>> >> write an opcode to do it in the most efficient way I could think of.
>> >>
>> >> I've got some more things to test and add, but there are currently 4
>> >> working version of it, so I thought I would share it and see what you
>> >> guys think.
>> >>
>> >> ps. I think that all the code should compile as plain C aswell as C++,
>> >> but I haven't tried it yet.
>> >>
>> >> Pete
>> >>
>> >> --
>> >> http://algorythmradio.com
>> >> https://soundcloud.com/algorythmradio
>> >>
>> >> Csound mailing list
>> >> Csound@listserv.heanet.ie
>> >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> >> Send bugs reports to
>> >>         https://github.com/csound/csound/issues
>> >> Discussions of bugs and features can be posted here
>> >
>> >
>> > Csound mailing list Csound@listserv.heanet.ie
>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> > https://github.com/csound/csound/issues Discussions of bugs and features
>> > can
>> > be posted here
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here



-- 
http://algorythmradio.com
https://soundcloud.com/algorythmradio

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

As an extra bit of info, what I was trying to do at the beggining of
these experiments was to replicate a sound from the Arturia Minibrute.
The metallized triangle wave in particular. It is the only thing
that's stopped me selling the Minibrute, I love the sound it makes,
and I've done a fair bit of research into how to do it, but never
quite pulled it off. The ftable "gifTriMet1" is a crude drawing that I
copied from an image from the manual, claiming to be roughly what the
metallized triangle wave looks like.

How I came about the idea of wobbling the ftable, was thanks to a
video comparison between the new Roland Boutique instruments and the
classic synths they are meant to be emulating (the Jupiter, Juno and
JX). When they compared the triangle wave, I noticed the classic
analogue wave was a bit wobbly on the oscilloscope, and sounded much
nicer. So I thought I'd throw that into the mix and see if small
amounts of wobble would help me get a more "analogue" feel. As it
happens, large amounts of wobble, combined with a mirror based
limiter, also gives an effect similar to the metallizer.

Pete

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Thanks alot! I would be more than happy for them to go into cabbage,
or be used elsewhere, with whatever edits you like.

I don't think I am constructing a new table each k-cycle, but I am
certainly altering the values each k-cycle, and maybe re-initing the
table each time. It's saving to the same table each time at least.
There definitely are more efficient implementations, which is why I
wrote the opcode version.

In the sources I posted, there are 4 versions so far. Two that add
wobble to ever sample without question, like in the .csd, one with
normalisation and one without, then two that allow you to specify how
many of the samples get wobbled, which spreads the amount of samples
evenly throughout the table, and interpolates the wobble between each
of these samples, again one with normalisation, and one without. I'm
also going to test out a "max wobble speed" control, and might even
see if I can alter the amount of sample wobbles at k-rate...  though
it'll probably be a nightmare to get working, i reckon it could add
some interesting timbral control.

Rich: Not sure why it's failing for you, both version are running
here, I'm on ubuntu. Though I think I already posted one of these up,
and I seem to remember that someone on Mac said then that it had
failed then aswell.

On Sat, Apr 16, 2016 at 1:47 PM, Dr. Richard Boulanger
 wrote:
> Peter,
>
> Thanks for making and sharing.
> Really nice instruments.  They do sound like the Korg MiniBrute too.  Love
> that!
> Inspiring use of jitter for sure.
> Looking forward to seeing/comparing the recursive version the Rory has
> proposed.
> Excited to have your Metallizers in Cabbage too.
>
> NOTE: Metallizer crashes, but metallizerDetuned works on my Mac.
> - using OSX 10.11.4  CsoundQt 0.9.2.1 Csound version 6.07 (double samples)
> Apr 1 2016
>
> On Sat, Apr 16, 2016 at 8:37 AM, Rory Walsh  wrote:
>>
>> These are very nice. When I see all those repeated lines of code I
>> immediately think of using a do-while loop, or a recursive UDO. I've a few
>> questions, are you reinit-ing on every k-pass for the entire duration of the
>> instrument? And it looks like you are also constructing a new table on each
>> k-cycle. I'm sure there are more efficient ways of doing this. Although I
>> didn't suffer any dropouts and problems when running the instrument. But I
>> wonder if you could simply create a single table. Then use a krate array to
>> hold all the jitter values, you could fill them in a recursive UDO, then use
>> copya2ftab to write them to the table? Might reduce the lines of code by
>> about 75%? Anyhow, nice stuff. I build a Cabbage synth around it if you
>> don't mind? If I do I'll be sure to share it with the rest of teh Cabbage
>> guys, and obviously credit you with the innovate use of jitter!
>>
>> On 16 April 2016 at 11:26, Peter Burgess 
>> wrote:
>>>
>>> As an extra bit of info, what I was trying to do at the beggining of
>>> these experiments was to replicate a sound from the Arturia Minibrute.
>>> The metallized triangle wave in particular. It is the only thing
>>> that's stopped me selling the Minibrute, I love the sound it makes,
>>> and I've done a fair bit of research into how to do it, but never
>>> quite pulled it off. The ftable "gifTriMet1" is a crude drawing that I
>>> copied from an image from the manual, claiming to be roughly what the
>>> metallized triangle wave looks like.
>>>
>>> How I came about the idea of wobbling the ftable, was thanks to a
>>> video comparison between the new Roland Boutique instruments and the
>>> classic synths they are meant to be emulating (the Jupiter, Juno and
>>> JX). When they compared the triangle wave, I noticed the classic
>>> analogue wave was a bit wobbly on the oscilloscope, and sounded much
>>> nicer. So I thought I'd throw that into the mix and see if small
>>> amounts of wobble would help me get a more "analogue" feel. As it
>>> happens, large amounts of wobble, combined with a mirror based
>>> limiter, also gives an effect similar to the metallizer.
>>>
>>> Pete
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
>
>
>
> --
> _____________________________________________
> Dr. Richard Boulanger
> Professor of Electronic Production and Design
> Professional Writing and Music Technology Division
> Berklee College of Music
> ______________________________________________
> President of Boulanger Labs - http://boulangerlabs.com
> Author & Editor of The Csound Book -
> http://mitpress.mit.edu/books/csound-book
> Author & Editor of The Audio Programming Book -
> http://mitpress.mit.edu/books/audio-programming-book
> ______________________________________________
> about: http://www.boulangerlabs.com/about/richardboulanger/
> about: http://www.csounds.com/community/developers/dr-richard-boulanger/
> music:
> http://www.csounds.com/community/developers/dr-richard-boulanger/dr-richard-boulanger-music/
> ______________________________________________
> email: rboulanger@berklee.edu
> facebook: https://www.facebook.com/richard.boulanger.58
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Saving the new values to the same table is probably a bad move,
because then the jitter doesn't have a point to centre round. That
said, I would of thought that would have given you pure noise rather
than limited effect... I'm struggling to work out your while loops.
What are the different kcount segments for? As a side note, it looks
to me like some of your figures are wrong there regarding the
"kcount wrote:
>> I don't think I am constructing a new table each k-cycle, but I am
>> certainly altering the values each k-cycle, and maybe re-initing the
>> table each time. It's saving to the same table each time at least.
>> There definitely are more efficient implementations, which is why I
>> wrote the opcode version.
>
>
> I think ftgenonce allocates and constructs a table each time it is called,
> but it seems to do it very efficiently. I've a version (not as good as your
> yet) that simply writes the values to an existing table, but it needs a
> little love. The one neat thing about constructing the table each time is
> that you don't have to make sure your values are normalised. When I do it my
> way (see attached), I have to make sure none of the values are greater than
> -/+1. And then when I sum the magic jitter it also have to be within. Hmmm.
> I wonder if there isn't an easier to do it? Is there a magic normalise table
> function I can call? Maybe you can also spot  few other little things taht
> are preventing this from working as good as yours!
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Ah right yeah, that makes sense now! What does it look like with
fairly strong jitter then? I have a feeling you may be suffering from
the same problem steven picked up on in my attempt at delay. Because
jitter has state, the call to jitter in each while loop will keep
refreshing the state I think. That might mean that the jitter will
only ever make it move 1 ksamps worth of distance away from it's
origin rather than the maximum jitter amplitude away from origin,
because by the time it gets to the next ksamp, the jitter will have
reset, and it'll be jittering from origin again. That might not be
right, I'm only guessing at how jitter's internals work here, but it
seems at least plausable.

On Sat, Apr 16, 2016 at 6:39 PM, Rory Walsh  wrote:
> The while lops construct an entire 64 sample triangle wave each time the UDO
> is called, and sum some jitter to it.  Adding jitter to each point in the
> triangular is what you're doing is it not? Each loop creates the next upward
> or downward section. They definitely create teh correct triangular
> waveshape, if you leave out the jitter they replicate the same wave as is
> defined in the ftgen call above it. I've tested that. In fact, the print
> calls are still there, but commented.
>
> On 16 April 2016 at 18:27, Peter Burgess 
> wrote:
>>
>> Saving the new values to the same table is probably a bad move,
>> because then the jitter doesn't have a point to centre round. That
>> said, I would of thought that would have given you pure noise rather
>> than limited effect... I'm struggling to work out your while loops.
>> What are the different kcount segments for? As a side note, it looks
>> to me like some of your figures are wrong there regarding the
>> "kcount>
>> As a thought, are your while loops doing the entire table each kcycle,
>> or just one sample?
>>
>> On Sat, Apr 16, 2016 at 5:46 PM, Rory Walsh  wrote:
>> >> I don't think I am constructing a new table each k-cycle, but I am
>> >> certainly altering the values each k-cycle, and maybe re-initing the
>> >> table each time. It's saving to the same table each time at least.
>> >> There definitely are more efficient implementations, which is why I
>> >> wrote the opcode version.
>> >
>> >
>> > I think ftgenonce allocates and constructs a table each time it is
>> > called,
>> > but it seems to do it very efficiently. I've a version (not as good as
>> > your
>> > yet) that simply writes the values to an existing table, but it needs a
>> > little love. The one neat thing about constructing the table each time
>> > is
>> > that you don't have to make sure your values are normalised. When I do
>> > it my
>> > way (see attached), I have to make sure none of the values are greater
>> > than
>> > -/+1. And then when I sum the magic jitter it also have to be within.
>> > Hmmm.
>> > I wonder if there isn't an easier to do it? Is there a magic normalise
>> > table
>> > function I can call? Maybe you can also spot  few other little things
>> > taht
>> > are preventing this from working as good as yours!
>> >
>> > Csound mailing list Csound@listserv.heanet.ie
>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> > https://github.com/csound/csound/issues Discussions of bugs and features
>> > can
>> > be posted here
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

And finally, with a much smaller UDO (i should have thought of this before!). In this example it's easy to switch table shapes because I build a new table based on 3 original tables that don't ever change. This stops the table from degrading to noise, which is exactly what happened when I tried the idea outlined in my previous post. Thanks again for posting, this creates some very nice sounds. Btw, have you given any thought to the issue of aliasing?

On 17 April 2016 at 12:14, Rory Walsh <rorywalsh@ear.ie> wrote:

Here's a full Cabbage example. I added another oscillator with a detune function and some reverb controls too. So the one limitation with my approach is that my UDO always builds its tables as triangular wave. So what I'm gong to try next is to simply have it modify each point in a table of any shape. The problem with that is that the table will slowly but surely move quite a distance from the its original shape. But I guess I can regenerate it on each key press. I'll give it a shot. It would mean I can get rid of the 4 if statements, and we can use any size tables. I guess your own opcode can already handle all these things, but it's fun to also implement it in native Csound code ;) 

On 17 April 2016 at 11:04, Rory Walsh <rorywalsh@ear.ie> wrote:

Looks like that was it alright. A recursive UDO does the trick. I'll tidy up my code a little before posting.

On 17 April 2016 at 10:51, Rory Walsh <rorywalsh@ear.ie> wrote:

I'll try a recursive UDO then and see if that's better.

On 16 April 2016 at 21:56, Peter Burgess <pete.soundtechnician@gmail.com> wrote:

Ah right yeah, that makes sense now! What does it look like with
fairly strong jitter then? I have a feeling you may be suffering from
the same problem steven picked up on in my attempt at delay. Because
jitter has state, the call to jitter in each while loop will keep
refreshing the state I think. That might mean that the jitter will
only ever make it move 1 ksamps worth of distance away from it's
origin rather than the maximum jitter amplitude away from origin,
because by the time it gets to the next ksamp, the jitter will have
reset, and it'll be jittering from origin again. That might not be
right, I'm only guessing at how jitter's internals work here, but it
seems at least plausable.

On Sat, Apr 16, 2016 at 6:39 PM, Rory Walsh <rorywalsh@ear.ie> wrote:
> The while lops construct an entire 64 sample triangle wave each time the UDO
> is called, and sum some jitter to it.  Adding jitter to each point in the
> triangular is what you're doing is it not? Each loop creates the next upward
> or downward section. They definitely create teh correct triangular
> waveshape, if you leave out the jitter they replicate the same wave as is
> defined in the ftgen call above it. I've tested that. In fact, the print
> calls are still there, but commented.
>
> On 16 April 2016 at 18:27, Peter Burgess <pete.soundtechnician@gmail.com>
> wrote:
>>
>> Saving the new values to the same table is probably a bad move,
>> because then the jitter doesn't have a point to centre round. That
>> said, I would of thought that would have given you pure noise rather
>> than limited effect... I'm struggling to work out your while loops.
>> What are the different kcount segments for? As a side note, it looks
>> to me like some of your figures are wrong there regarding the
>> "kcount<x" and "x-kcount" bits.
>>
>> As a thought, are your while loops doing the entire table each kcycle,
>> or just one sample?
>>
>> On Sat, Apr 16, 2016 at 5:46 PM, Rory Walsh <rorywalsh@ear.ie> wrote:
>> >> I don't think I am constructing a new table each k-cycle, but I am
>> >> certainly altering the values each k-cycle, and maybe re-initing the
>> >> table each time. It's saving to the same table each time at least.
>> >> There definitely are more efficient implementations, which is why I
>> >> wrote the opcode version.
>> >
>> >
>> > I think ftgenonce allocates and constructs a table each time it is
>> > called,
>> > but it seems to do it very efficiently. I've a version (not as good as
>> > your
>> > yet) that simply writes the values to an existing table, but it needs a
>> > little love. The one neat thing about constructing the table each time
>> > is
>> > that you don't have to make sure your values are normalised. When I do
>> > it my
>> > way (see attached), I have to make sure none of the values are greater
>> > than
>> > -/+1. And then when I sum the magic jitter it also have to be within.
>> > Hmmm.
>> > I wonder if there isn't an easier to do it? Is there a magic normalise
>> > table
>> > function I can call? Maybe you can also spot  few other little things
>> > taht
>> > are preventing this from working as good as yours!
>> >
>> > Csound mailing list Csound@listserv.heanet.ie
>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> > https://github.com/csound/csound/issues Discussions of bugs and features
>> > can
>> > be posted here
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here



--
http://algorythmradio.com
https://soundcloud.com/algorythmradio

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Great work! I'll test these out when I get back. In the opcode, I also went for separate tables for the original wave, the wobble and the final outcome. As for aliasing, I have not! I have different versions of the opcode. I reckon I could work an anti aliasing version in. However, one my opcodes allows you to create only a limited amount of wobbles, so you can have big tables without excessive "wobble noise". Not sure if that will aid in aliasing or not though.... Otherwise you could try running it through a new gen 30 table... Is it gen 30 that can create a band limited version?

For polyphony, I guess it's a case of whether you want a separate wobble table for each note, or one for all of them. This leads us to some interesting realms! I'll try polyphony with my opcode, see how it pans out, and I'll post some audio examples of the results. I'll also see how many notes I can get before I hit problems.

How do opcodes get officially added to Csound BTW? Can anyone decide to add one, or do the dev guys need to agree? Or otherwise?

On Sun, 17 Apr 2016, Peter Burgess wrote:

> 
> How do opcodes get officially added to Csound BTW? Can anyone decide to add
> one, or do the dev guys need to agree? Or otherwise?
>

There is no official way.  Developers just do it, others get submitted via 
one of the mailing lists and discussion there.  If there is enough interest 
it gets incorporated.  Chances improve with clean code, manual page 
and example use.

Perhaps we need a policy but what we ave has worked so far.

==John

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Ok cool, when I've got the opcode nailed, I'll post it again and see what you guys think