Shematic for Teensy 4.1 compatible Pt8211-Kit?

PaulStoffregen · May 30, 2022

TheHermit said:
As previously mentioned, I can also test the same 'broken' sketch on a different PC and it will work reliably, using the same T4laser synth module. I have disabled installing updates on that Arduino's IDE, in hopes of protection against kremlins. So far, so good.
The only difference is using different computers, both Win 10, both I5 intel, but the Surface is several years older, with an out of date HAL for MS to upgrade. to Win 11.
Yes, I understand that you don't have the ability to troubleshoot, without being able to reproduce it at your end. I can't detect any problems on the miniPC, either.

Any chance anti-virus or windows defender or other anti-malware could be interfering with the compiler? Or the installer writing the files?

boxxofrobots · May 30, 2022

Here's the /tmp files for the build, and the code (which results in no output). Thanks again.

Code:

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>



// GUItool: begin automatically generated code
AudioSynthWaveform       waveform1;      //xy=1341,274
//AudioOutputI2S       i2s1;      //xy=1709,230
AudioOutputPT8211_2      pt8211_2_1;     //xy=1726,313
//AudioConnection          patchCord4(waveform1, 0, i2s1, 0);
AudioConnection          patchCord5(waveform1, 0, pt8211_2_1, 0);
AudioConnection          patchCord6(waveform1, 0, pt8211_2_1, 1);
// GUItool: end automatically generated code


void setup() {
  AudioMemory(15);
  waveform1.begin(WAVEFORM_SINE);
  waveform1.frequency(440);
  waveform1.amplitude(0.99);
}

void loop() {
}

boxxofrobots · May 30, 2022

This morning I reproduced the problem on a t420 thinkpad with a fresh install of ubuntu 20.04 focal fossa. I did not change any of the machine's configuration other than downloading and installing arduino1.8.19 and teensyduino 1.56. When I compiled the program above I got the exact same results - no sound. Uncomment the two lines referring to i2s1 and it works.

Is it possible there's a regression in the linux version? Should I download the windows version and manually unpack the audio library?

PaulStoffregen · May 30, 2022

boxxofrobots said:
Here's the /tmp files for the build,

I programmed this HEX file (msg #52) onto my Teensy 4.1, and sure enough I can reproduce the problem. I'm getting clocks on pins 3 & 4, but pin 2 is stuck low.

Going to start looking inside the ELF file to see if I can uncover any clues about what's causing this....

TheHermit · May 30, 2022

The compiler absolutely uses the class name to determine whether to use the code for pins 7,20,21 versus 2,3,4.

Yes, I understand that's how it is supposed to work. Thank you for checking the code to confirm that's not the issue, Paul.

The design tool is completely separate from the compiler. It's just a GUI that outputs text.

Ahh, you obviously read my comment before I realized exactly that and deleted the suggestion of it being a possibility. You're amazingly on top of your game.

PaulStoffregen · May 30, 2022

Well, I ran "arm-none-eabi-objdump -d -S -C" to disassemble the elf file. It gives me the assembly list, but "-S" doesn't seem to work. I don't get the source code lines inserted into the list output. I ran it just now on an .elf file compiled by my Linux machine and I do get the source lines. Can't understand how this .elf file is different. Maybe the Windows version isn't quite the same format?

TheHermit · May 30, 2022

Hmm... You're having this problem on a 2011 I5 notebook, while I'm having the same problem on a 2013 Surface Pro 2 (discontinued production in 2014). But, my I5 miniPC, purchased only last year doesn't have the problem. Makes me wonder about the older HAL. But still doesn't explain why some sketches work, while others don't.

Should I download the windows version and manually unpack the audio library?

Inside a Windows VM on Ubuntu? The Windows version isn't working for me on Windows 10. But, if you know how do it, you're a better man than I. At this point, any straw is worth grasping for, I suppose.
I'll see if I can find a basic sketch, with only the PT8211, that works on my Surface, then send you a copy to test on your Thinkpad.
BR

boxxofrobots · May 30, 2022

I guess we're both lost then, because I don't know from Windows. I haven't used it since I retired nearly a decade ago.

I don't know if this is a clue, but if you build the above sketch with usb audio out as well, you'll find that with no i2s1 defined and use only the pt8211_2 object, it won't even make the clock to run usb output.

TheHermit · May 30, 2022

boxxofrobots
Don't despair, my friend. I just learned something while trimming down one of my working sketches for you. After deleting all of the laser fluff, I only had 4 waveforms feeding a mixer on L/R channels on the pt8211 (a little Easter egg for your o'scope. ;-). Plus DC objects for RGB to light the laser projector. The sketch worked fine, until I commented out the patch chords to the I2S Quad object. Sound familiar?
Would it be safe to conclude that the I2SQuad object needs those inputs to e actively connected, before it utilizes those I2S channels in order to 'push' the PT8211 onto the next available I2S port on pin #2?
On the other hand, that doesn't still doesn't solve my problem on the Surface. Still can't get my latest sketch to work, which was written on the miniPC and runs fine there. I'll be moving on to that, now.
Anyway, here's my sketch that i prepared for you (+ whomever is interested).

Update: I just tested that possible conclusion by only deleting the third patch chord (4th already didn't exist) to the I2S quad object to free up one I2S port. Shore-nuf, the DIN signal on pin #2 ceased to exist. RIP.

KurtE · May 30, 2022

For what it is worth I downloaded the sketch #52 and built it on Windows 10. Note My Audio library is github synced to what is currently checked in.

I hooked up Logic Analyzer to pins 2-4 and ran it and show both the digital values for each pin as well as what it thinks the analog value is.

Note: I did get a few compiler warnings:

Code:

"C:\\arduino-1.8.19\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=157 -DARDUINO=10819 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_624708/pch" "-IC:\\arduino-1.8.19\\hardware\\teensy\\avr\\cores\\teensy4" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\Audio" "-IC:\\arduino-1.8.19\\hardware\\teensy\\avr\\libraries\\SPI" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\SD\\src" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\SdFat\\src" "-IC:\\arduino-1.8.19\\hardware\\teensy\\avr\\libraries\\SerialFlash" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\Wire" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\Audio\\utility" "C:\\Users\\kurte\\Documents\\Arduino\\libraries\\Audio\\output_spdif3.cpp" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_624708\\libraries\\Audio\\output_spdif3.cpp.o"
C:\Users\kurte\Documents\Arduino\libraries\Audio\output_pwm.cpp: In static member function 'static void AudioOutputPWM::isr()':
C:\Users\kurte\Documents\Arduino\libraries\Audio\output_pwm.cpp:370:29: warning: invalid conversion from 'volatile audio_block_t* {aka volatile audio_block_struct*}' to 'audio_block_t* {aka audio_block_struct*}' [-fpermissive]
   AudioStream::release(block);
                             ^
In file included from C:\Users\kurte\Documents\Arduino\libraries\Audio\output_pwm.h:31:0,
                 from C:\Users\kurte\Documents\Arduino\libraries\Audio\output_pwm.cpp:28:
C:\arduino-1.8.19\hardware\teensy\avr\cores\teensy4/AudioStream.h:160:14: note:   initializing argument 1 of 'static void AudioStream::release(audio_block_t*)'
  static void release(audio_block_t * block);
"C:\\arduino-1.8.19\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=157 -DARDUINO=10819 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_624708/pch" "-IC:\\arduino-1.8.19\\hardware\\teensy\\avr\\cores\\teensy4" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\Audio" "-IC:\\arduino-1.8.19\\hardware\\teensy\\avr\\libraries\\SPI" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\SD\\src" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\SdFat\\src" "-IC:\\arduino-1.8.19\\hardware\\teensy\\avr\\libraries\\SerialFlash" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\Wire" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\Audio\\utility" "C:\\Users\\kurte\\Documents\\Arduino\\libraries\\Audio\\output_tdm2.cpp" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_624708\\libraries\\Audio\\output_tdm2.cpp.o"              ^

C:\Users\kurte\Documents\Arduino\libraries\Audio\output_pwm.cpp: In member function 'virtual void AudioOutputPWM::update()':
C:\Users\kurte\Documents\Arduino\libraries\Audio\output_pwm.cpp:402:12: warning: invalid conversion from 'volatile audio_block_t* {aka volatile audio_block_struct*}' to 'audio_block_t* {aka audio_block_struct*}' [-fpermissive]
  old_block = block ;

TheHermit · May 30, 2022

Thank you for the info, KurtE.
Yes, time for me to fess-up. I just discovered a problem in a section of code that was causing no x/y output signals. Looks like I made a mistake while learning to use 2 dimensional arrays. That' why an older sketch worked.
Same symptom as before, but different cause. I shouldn't have ass-u-med
The problem wasn't in having no DIN, but too much DIM (as in wit).
I sincerely apologize to everyone for the false alarm.
My problem has been resolved. But, boxxofrobots is still having DIN issues with configuring his pt8211. Hopefully, my contribution to that was helpful.
BR.

PaulStoffregen · May 30, 2022

Earlier today mjs513 noticed the code from msg #52 enumerates as "Serial + MIDI + Audio".

So I ran tests with all USB Type settings on different versions. I used the code from msg #35 (because it was still on my screen), compiling on my Linux desktop which runs Ubuntu 20.04.

Code:

USB Type                                1.55    1.56    1.57b1+ 
--------                                ----    ----    ------  
Serial                                  Fail    OK      OK
Dual Serial                             Fail    OK      Fail
Triple Serial                           OK      OK      OK
Keyboard                                Fail    Fail    OK
Keyboard + Touchscreen                  Fail    OK      OK
Keyboard + Mouse + Touchscreen          Fail    Fail    OK
Keyboard + Mouse + Joystick             Fail    OK      OK
Serial + Keyboard + Mouse + Joystick    OK      Fail    Fail
MIDI                                    Fail    Fail    OK
MIDI x4                                 Fail    Fail    OK
MIDI x16                                Fail    Fail    OK
Serial + MIDI                           OK      Fail    Fail
Serial + MIDI x4                        OK      Fail    Fail
Serial + MIDI x16                       OK      Fail    Fail
Audio                                   Fail    OK      Fail
Serial + MIDI + Audio                   OK      Fail    OK
Serial + MIDI x16 + Audio               OK      Fail    OK
MTP Disk (experimental)                 OK      OK      OK
RawHID                                  OK      OK      Fail
Flight Sim                              OK      Fail    Fail
Flight Sim + Joystick                   OK      Fail    Fail

With USB Type set to the default Serial, the bug happens with 1.55 and goes away with 1.56 and 1.57-beta1... which is why I remembered this bug associated with 1.55 and believed we had fixed it with 1.56. But it looks like this problem has been with us for quite a long time and it's present or vanishes depending on a lot of difficult to anticipate factors.

While this looks like a conflict with USB, my gut feeling is we're probably looking at a deeper problem called C++ Static Initialization Order Fiasco.

I will (eventually) get to the bottom of this (unless someone else beats me to it), but right now I need to put on my IT maintenance hat and work on the PJRC website. We had a problem over the weekend where our credit card processing service shut down. Need to work on that now, but will come back to this soon.

Just wanted to share this insight, that the problem depends on USB Type and probably the linker's ordering of all other C++ static instances.

boxxofrobots · May 30, 2022

It's alive! The sound is bauhaus, not my creation, but I have since used the AudioObjectI2C workaround to get the sound working (for now). Ultimately I need 7,20 and 21 for serial, but they're ok for now.

Thanks Paul for your prompt attention on this. I'll patiently wait for any followup you might have about this.

TheHermit · May 31, 2022

Thanks Paul!
That explains the inconsistent failures with some of my sketches.
However, boxxofrobots presented another caveat (msg #24), regarding the patch Cord connections to the I2S_QUAD_DAC, while trying to configure the solo PT8211 to use pin # 2 for DIN.
With the SGTL5000 shields installed and being used, here are my test results, which are different from yours The sketch is the same as in msg #59. (x/y scope setting recom'd ;-)
For your convenience, I've also added the results of all combinations of the 4 patchCords being commented out.
x = patchCord Connection commented out
C = Connected

Code:

USB Type                                1.55    1.56   Hermit's 1.56 
                                                       w/quad SGTL5000 + PT8211 
                                                       DIN on pin #2
--------                                ----    ----    ------  
Serial                                  Fail    OK      OK
MIDI                                    Fail    Fail    Fail
MIDI x4                                 Fail    Fail    Fail
MIDI x16                                Fail    Fail    Fail
Serial + MIDI                           OK      Fail    OK
Serial + MIDI x4                        OK      Fail    OK
Serial + MIDI x16                       OK      Fail    OK
Audio                                   Fail    OK      OK
Serial + MIDI + Audio                   OK      Fail    OK
Serial + MIDI x16 + Audio               OK      Fail    OK


AudioConnection          patchCord14(X_MIX, 0, I2S_QUAD_DAC, 0);
AudioConnection          patchCord11(R_DC, 0, I2S_QUAD_DAC, 1);
AudioConnection          patchCord12(G_DC, 0, I2S_QUAD_DAC, 2);
AudioConnection          patchCord13(B_DC, 0, I2S_QUAD_DAC, 3);


                           I2S_QUAD_DAC Ports     Hermit's
USB Type                   3     2     1     0     1.56
--------                  ----  ----  ----  ----   ----  
Serial + MIDI x4            x    x     x    x       Fail   
Serial + MIDI x4            x    x     x    C       OK   
Serial + MIDI x4            x    x     C    x       OK   
Serial + MIDI x4            x    x     C    C       Fail
Serial + MIDI x4            x    C     x    x       OK   
Serial + MIDI x4            x    C     x    C       Fail   
Serial + MIDI x4            x    C     C    x       Fail   
Serial + MIDI x4            x    C     C    C       Fail
Serial + MIDI x4            C    x     x    x       OK  
Serial + MIDI x4            C    x     x    C       Fail   
Serial + MIDI x4            C    x     C    x       Fail   
Serial + MIDI x4            C    x     C    C       OK
Serial + MIDI x4            C    C     x    x       Fail   
Serial + MIDI x4            C    C     x    C       OK   
Serial + MIDI x4            C    C     C    x       OK   
Serial + MIDI x4            C    C     C    C       OK

It appears that:
* at least one of of any patchChords must be connected, and
* only 2 of any patchChord connections always fails

Hope this info helps.

TheHermit · May 31, 2022

Congrats boxxofrobots!
Are you aware of being able to move serial ports to different pins, by using Wire2?

boxxofrobots · May 31, 2022

Wire2? Oh no, more stuff to learn!

Right now I've not even enabled port1. I'm back to working on the synth engine because that's more fun than dealing with linker issues

I have to get the sequencers and modulation sources mastered before it'll need to connect to other synths.

https://www.youtube.com/watch?v=urU0yOVOBMk

The truth is out there...

TheHermit · May 31, 2022

Okay. So how would you like to hear a pair of boring, phase shifting 1kHz Left & 501kHz Right, (aka rotating x/y figure 8 on a scope.) coming from your PT8211, using pin # 2 for DIN?
Here ya go, but you need to set your USB type to either Serial or Serial + MIDI + Audio. Setting it to Audio breaks it.
Looks like Paul nailed the solution for both of us.
WooHoo!

Code:

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>


// GUItool: begin automatically generated code
AudioSynthWaveform       X_OSC1;         //xy=304.98876953125,28.000000953674316
AudioSynthWaveform       Y_OSC1;         //xy=304.98876953125,169.00000095367432
AudioOutputPT8211_2      pt8211_2;       //xy=681.9888191223145,117.0000057220459
AudioConnection          patchCord1(X_OSC1, 0, pt8211_2, 0);
AudioConnection          patchCord2(Y_OSC1, 0, pt8211_2, 1);
// GUItool: end automatically generated code

// GLOBAL VARIABLES
const byte BUFFER = 8; //Size of keyboard buffer

void setup() {
  AudioMemory(20);


  X_OSC1.begin(.5,1000,WAVEFORM_SINE); 
  Y_OSC1.begin(.5,501,WAVEFORM_SINE); 

   }

boxxofrobots · May 31, 2022

I just installed 1.57b1 and I still get the same result when building knobby. Commenting out the references to i2s2 (leaving only usb audio and pt8211_2) causes no sound output from the 8211.

Just trying to help.

TheHermit · May 31, 2022

LOL!
Just noticed that you're from Tucson. So am I!
Does it work with the USB Type set to 'Serial' or 'Serial + MIDI + Audio"? That's the key.

mjs513 · Jun 1, 2022

@PaulStoffregen - @KurtE - @TheHermit and all interested

@KurtE and I was playing a bit more this morning with this issue. The one thing that I noticed between output_pt2811.cpp and ouput_pt2811_2.cpp was that config_i2s was wrapped in FLASHMEM in output_pt2811_2.cpp. So as a test (just to make the two classes more in line) we removed FLASHMEM from ouput_pt2811_2.cpp.

Using a multimeter on pin 2 tested the following (1.57b1+):

Code:

DUAL SERIAL - OK
SERIAL - OK
SERIAL+MIDIx16 - OK
SERIAL+MIDIx15+AUDIO - OK
RawHID - OK

@KurtE attached a LA to and tested with DUAL SERIAL as well.
Without the change pin 2 is flatlined:

with deleting FLASHMEM from in front of config_i2s

If someone can test the change with actual h/w since I dont have a PT2811 soldered up it would be good.

KurtE · Jun 1, 2022

Good catch @mjs513

Sometimes I really really wish the code was setup to use data structures instead of hard coded register names, such that you don't have duplicate files with probably 90% the same except for the register names...

That is I wish that there was an SAI data structure defined, such that then hopefully you could just pass in pointer to structure... And use the same code...

maybe something like:

Code:

typedef struct {
	const    uint32_t VERID;		// offset000
	volatile uint32_t PARAM;		// offset004
	volatile uint32_t TCSR;			// offset008
	volatile uint32_t TCR1;			// offset00C
	volatile uint32_t TCR2;			// offset010
	volatile uint32_t TCR3;			// offset014
	volatile uint32_t TCR4;			// offset018
	volatile uint32_t TCR5;			// offset01C
	volatile uint32_t TDR[4];		// offset020
	const   uint32_t UNUSED0[4];    // 030
	volatile uint32_t TFR[4];		// offset040
	const   uint32_t UNUSED1[4];    // 050
	volatile uint32_t TMR;			// offset060
	const   uint32_t UNUSED2[9];    // 064,8,C,070,4,8,c,080,4
	volatile uint32_t RCSR;			// offset088
	volatile uint32_t RCR1;			// offset08C
	volatile uint32_t RCR2;			// offset090
	volatile uint32_t RCR3;			// offset094
	volatile uint32_t RCR4;			// offset098
	volatile uint32_t RCR5;			// offset09C
	volatile uint32_t RDR[4];		// offset0A0
	const   uint32_t UNUSED3[4];    // 0B0
	volatile uint32_t RFR[4];		// offset0C0
	const   uint32_t UNUSED4[4];    // 0D0
	volatile uint32_t RMR;			// offset0E0
} IMXRT_SAI_t;

Which all of the defines could still be defined like they are...

Code:

#define IMXRT_I2S1		(*(IMXRT_REGISTER32_t *)IMXRT_I2S1_ADDRESS)
// I2S1 requires CCM_CCGR5_SAI1
#define I2S1_VERID			(IMXRT_I2S1.offset000)
#define I2S1_PARAM			(IMXRT_I2S1.offset004)
#define I2S1_TCSR			(IMXRT_I2S1.offset008)
...

But better yet if they were done like some of the other structures...

Code:

#define IMXRT_I2S1		(*(IMXRT_SAI_t*)IMXRT_I2S1_ADDRESS)
#define I2S1_VERID			(IMXRT_I2S1.VERID)
#define I2S1_PARAM			(IMXRT_I2S1.PARAM)
#define I2S1_TCSR			(IMXRT_I2S1.TCSR)
...

Or better yet with SAI...

Oops, sorry maybe I need some more coffee!
Just sometimes it is hard to know when two code bases are slightly different if there as a reason for it?
Like why:

Code:

FLASHMEM
void AudioOutputPT8211_2::config_i2s(void)

versus

Code:

void AudioOutputPT8211::config_i2s(void)

Was one marked as FLASHMEM and the other was not for some reason? Maybe earlier on main object found it did not work and never checked on version 2? Or was it added to version 2 as a pass through trying to reduce ITCM memory usage and this strangeness was not detected?

Now to get another cup

TheHermit · Jun 1, 2022

@mjs513
Thanks for the help, but I'm still on 1.56 and in the middle of developing a project with very expensive equipment. As a novice, I'm already struggling with stable libraries and my gut tells me that it would be foolish to potentially multiply my woes with beta libraries.
But, if it's any help, as I indicated in msg #64, all of the Serial* USB options are already working for me, except whenever only 2 patchCords are connected to the I2SQuad inputs (which I never need to do).
As I've demonstrated with the sketch in msg #67, a solitary PT8211_2 works just fine, w/o any I2S objects in the code, just connected directly to the waveform sources or mixers. Again, the USB Type must include 'Serial'.
I seriously appreciate your willingness to step up to the plate to resolve this issue. TBH, now that I'm aware of the correct USB settings to use, I'm a much happier camper.
BR.

TheHermit · Jun 1, 2022

mjs513 said:
I noticed between output_pt2811.cpp and ouput_pt2811_2.cpp was that config_i2s was wrapped in FLASHMEM in output_pt2811_2.cpp. So as a test (just to make the two classes more in line) we removed FLASHMEM from ouput_pt2811_2.cpp.

If someone can test the change with actual h/w since I dont have a PT2811 soldered up it would be good.

if it's any help, ver 1.56, config_i2s is also wrapped in FLASHMEM in output_pt8211_2.cpp.

TheHermit · Jun 1, 2022

Wouldn't this problem simply disappear, if the T4 PT8211_2 were only assigned to pins 2,3,& 4 and had a breakout PCB to match?
But, what does The Hermit know about this stuff, anyway?

KurtE · Jun 1, 2022

TheHermit said:
if it's any help, ver 1.56, config_i2s is also wrapped in FLASHMEM in output_pt8211_2.cpp.

The problem is, the FLASHMEM is appearing to cause this problem. SO simply remove that keyword... that was the only change.

And then see if things work for you.

Shematic for Teensy 4.1 compatible Pt8211-Kit?

Well-known member

Well-known member

Attachments

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Attachments

Senior Member+

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Senior Member+

Senior Member+

Well-known member

Well-known member

Well-known member

Senior Member+